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I . GENERAL INTRODUCTION 



This report has been prepared to bring to the attention of the Naval Air 
Systems Command (NAVAIRSYSCOM AIR-420) deficiencies associated with its Manage- 
ment Information System (MIS) and the supporting Maintenance Data Collection 
System (MDCS) and make recommendations for their improvement. 

A. BACKGROUND 

NAVAIRSYSCOM (AIR-420) is the Navy's designated systems command respon- 
sible for the logistics support of Air-Launched Missiles (ALMs). NAVAIRSYSCOM 
(AIR-420 1 s) function is the management (planning, programming, directing, and 
control) of field activities through specific delegated tasks to accomplish 
its mission. Since NAVAIRSYSCOM (AIR-420) does not own any missile mainte- 
nance or maintenance support activities, execution of these functions are 
assigned to other commands (e.g., supply to Naval Supply Systems Command (NAV- 
SUPSYSCOM) ; maintenance to Naval Sea Systems Command (NAVSEASYSCOM) . This 
separation of management and engineering from those activities performing 
supply support and maintenance is thus complicated by inter-command relation- 
ships. One such example of these relationships is MDCS. NAVAIRSYSCOM (AIR-420) 
has delegated MDCS to the Fleet Analysis Center (FLTAC), a NAVSEASYSCOM facil- 
ity. NAVAIRSYSCOM (AIR-420) has had difficulty in controlling the operation 
and outputs of MDCS through delegated tasking, and FLTAC has been unresponsive 
in the execution of its function. 

One of the more important missions of NAVAIRSYSCOM (AIR-420) is the accomp- 
lishment of maintenance and overhaul for the Navy's inventory of ALMs. This 
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inventory represents a large capital investment, wit le annual m "itena~ e 
budget estimated at 75 million dollars. The capital investment and support 
costs combine to form a significant ongoing business which is complex to 
manage . 

The maintenance system has three levels: the organizational, intermediate 

and depot levels of maintenance. The organizational level is performed by the 
Fleet operational activities. Intermediate maintenance is performed by NAV- 
SEASYSCOM weapon stations and Fleet Missile Maintenance Facilities (MMFs). 

Depot level of maintenance is performed by the Naval Air Rework Facility (NARF) 
Alameda and commercial companies. NAVAIRSYSCOM sets the maintenance policy 
for the organizational level, but the actual work is done by Fleet personnel. 
Intermediate level maintenance is primarily performed by weapon stations and 
is funded and managed by NAVAIRSYSCOM (AIR-420) with the actual scheduling and 
production accomplished by weapon station personnel. The same is true for 
depot level maintenance except the work is performed through contracting with 
commercial companies and by NAVAIRSYSCOM tasking and funding to the NARFs. 

Timely and accurate information i essential to NAVAIRSYSCOM management 
and NAVAIRSYSCOM Fleet engineering support functions. The core of this infor- 
mation is maintenance data. NAVAIRSYSCOM (AIR-420) is responsible to the Chief 
of Naval Operations (CNO) for accomplishment of its mission. The performance 
of NAVAIRSYSCOM (AIR-420) is measured by Asset Readiness (AR) in terms of 
specified objectives called Asset Readiness Objectives (AROs). NAVAIRSYSCOM 
is expected to meet these objectives in the most economical manner possible 
(reduction of maintenance burden). 
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B. STATEMENT OF NEED 



Inherent in the efficient accomplishment of the NAVAIRSYSCOM (AIR-420) 
mission is an efficient and credible MIS. It is essential that NAVAIRSYSCOM 
(AIR-420) and cognizant field activities have accurate and timely information 
from all the decentralized maintenance facilities and activities to efficiently 
accomplish their assigned mission. This accurate and timely information can 
best be gathered, collated, analyzed and compared to standards through the use 
of a modern MIS. The existing NAVAIRSYSCOM (AIR-420) MIS is antiquatld and 
has many deficiencies. 

The development of an air-launched missile information system that is both 
modern and adequate would benefit the Navy in terms of asset readiness, relia- 
bility of inventory, and decreased cost of maintenance. Asset readiness would 
be increased by decreasing missile logistics downtime, thereby increasing the 
number of missiles in Ready For Issue (RFI) condition. Better engineering 
decisions would be possible for product improvement, which would increase 
inventory reliability. Rapid access to information would help management 
minimize costly delays and pinpoint uneconomical maintenance actions. 

A modern MIS should have the capability to provide real-time reporting and 
analysis of all essential processes within the maintenance pipeline. A user 
should also be able to project the results of future maintenance processes 
based on qualitative or quantitative variables. The information supplied must 
be credible, understandable, and offer a reward for its use. Without these 
properties, the users will not accept ownership of the information and the 
system will fail. Ownership is best accomplished when the system is an 
integral part of the user’s organization. The significant number of users 
require that any new NAVAIRSYSCOM (AIR-420) MIS be a distributed network of 
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computers so that all participants have equal access and share responsibility 
for the data and information. The final responsibility for operation and 
management of the information system should be within the NAVAIRSYSCOM 
(AIR-420) organization to prevent inter-command conflicts. 

C. RESEARCH OBJECTIVES 

This report examines the characteristics of the existing MDCS and deter- 
mines its potential utility as the primary element in the development of a 
modern Maintenance Management Information Syster MMIS) . The objectives of 
the report are: 

1. Determine and analyze characteristics and capabilities of the present 
MDCS and MIS. 

2. Analyze the deficiencies of the existing MDCS. 

3. Propose system properties and management guidelines for the development 
of a new MMIS. 

4. Develop a conceptual model for a modern MMIS as the primary element of a 
modern MIS. 

D . REPORT CONTENTS 

The remaining portion of the report has been divided into six sections. 

Each of these sections is briefly described to orient the reader and assist in 
locating pertinent information. 

Section 2 presents the major conclusions and recommendations of the report. 
Conclusions and recommendations have been included as early as possible in the 
report to allow evaluation with a minimum of effort. Justification is con- 
tained in ensuing sections. 

Section 3 presents a more detailed background of Navy maintenance policy 
and the current NAVAIRSYSCOM (AIR-420) MIS structure as defined in OPNAVINST 
8600., The Naval Airborne Weapons Maintenance Program [Ref. 1]. This material 
has been included to provide the reader with a background of basic 
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NAVAIRSYSCOM processes which may be necessary for the understanding of sub- 
sequent sections of this report. 

Section 4 is a historical review of the MDCS which details capabilities 
and deficiencies. The historical approach was adopted in order to demonstrate 
how deficiencies emerged and to emphasize that they are persistent in nature. 
The persistence of deficiencies indicates that they are managerial rather than 
technical in nature. 

Section 5 presents material of a conceptual nature concerning the charac- 
teristics required for a new MMIS. This section contains two subsections. 

The first describes technology transfer principles which should be applied in 
the development of a new information system. Although philosophical in nature 
these principles are considered more fundamental to the successful development 
of a new system than technical requirements. The second subsection lists con- 
ceptual requirements of a technical nature for the new system. 

Section 6 briefly surveys the state of current information system techno- 
logy, and concludes that the primary potential difficulties in the development 
of a new information system are managerial rather than technological in nature 

Section 7 briefly describes a management systems approach which should be 
adopted for the development of the new system. 
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II. CONCLUSIONS AND RECOMMENDATIONS 



The following ten subsections present the major conclusions and recommen- 
dations of this report. 

A. MIS IS NOT FUNCTIONAL 

The MIS is defined as a major system of the ILSS, which provides the capa- 
bility for data gathering, analysis, display, and reporting in the management 
decision making process. The system consists of five components. However, in 
its current state the MIS is non-functional for the following reasons: 

1. Some components are not operating; 

2. Most components do not adequately fulfill their intended function; 

3. All components do not interface properly; 

4. Components do not combine to form an effective management information 
system. 

PMS, ICS, and PRABS are currently not operational or have fallen into dis- 
use. Only AWCAP appears to fulfill its intended function, but this subsystem 
would benefit from modernization. In a systems sense, none of the components 
interface properly. For example, AWCAP and PRABS are stand alone systems. 

PMS and ICS were clearly designed with the primary purpose of interfacing MDCS 
with MIS. Their failure isolates MDCS and makes access unfeasible. An effec- 
tive MIS cannot be developed from components which do not operated to fulfill 
their intended function or interface properly. Therefore, NAVAIRSYSCOM should 
begin restructuring the current MIS. 

B. MDCS IS UNWORKABLE 

Since the MIS is deficient as an information system, at least some of the 
components which combine to make up the MIS are accordingly unworkable. The 
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most important of these components, MDCS, has several serious deficiencies and 
should be abandoned as a means of monitoring air-launched missile status and 
history. Although the system basically conforms to the definitions published 
in the NAWMP, it has deteriorated into a useless mass of data, unintelligible 
to its users and developers. It is ultimately unworkable for the following 
reasons : 

1. Users do not have direct access to data files; 

2. Current report output is of marginal quality and reliability; 

3. Users have little or no data processing capability; 

4. Reliability of data element definitions is questionable; 

5. System documentation is inadequate; 

6. Timeliness of data entry is still in question. 

More importantly, MDCS lacks credibility with users. The lack of user con- 
fidence has produced continual efforts to subvert the system and obtain data 
by other means. However, even if MDCS deficiencies could be immediately cor- 
rected, significant user support could not be generated within the foreseeable 
future. A management information system cannot survive without the support of 
its users. 

C. DEVELOPMENT OF A NEW SYSTEM 

Considering the deficiencies of the MDCS listed above, remedial upgrade of 
MDCS appears to be a more significant effort than development of a new system. 
The development of a new system would avoid the user bias and obsolete tech- 
nology inherent in MDCS. The imposition of a systems approach with a phased 
implementation (including proper planning and evaluation) offers the highest 
probability of success. 

The final goal of this development effort should be a completely restruc- 
tured NAVAIRSYSCOM (AIR-420) MIS. The intent of this report is more limited 
in scope. The report recommends that MDCS be abandoned and replaced with a 
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new component called the Maintenance Management Information System (MMIS) . 

The MMIS would be a stand alone information system for the management of ALM 
maintenance. Implementation of the MMIS will fill a critical need in itself. 
The MMIS would also serve as the cornerstone of the restructured MIS through 
expansion upward and outward until all requirements for management information 
of the ALM community are satisfied. 

D. UTILIZATION OF TECHNOLOGY TRANSFER PRINCIPLES 

The principles of technology transfer should be considered in the con- 
ceptual formulation of the MMIS. In a general sense, technology transfer 
principles are contained in nine elements of the Linker Model and are con- 
sidered necessary for user acceptance of new developments or innovations. By 
applying technology transfer principles to information systems, the new MMIS 
becomes the linker between the members of the ALM maintenance community. 

Reward and penalty of the system should also be given careful attention. In 
the general sense, this means that there must be a reward for the use of an 
innovation or it will not be utilized. Consequently, products of the MMIS 
must offer a reward for their use to the members of the ALM community. The 
reward concept implies that MMIS conception starts with the definition of 
products as opposed to MDCS, which started with the definition of data 
elements. The MMIS must be product oriented. 

E. MMIS TECHNICAL REQUIREMENTS 

Research conducted in during the preparation of this report identified 
eleven technical requirements of a conceptual nature which should be 
incorporated in the MMIS. 
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1. The system must be controllable and auditable. 

2. The system must have integrity. 

3. The system should be economical to operate. 

4. The system must be user friendly. 

5. Data must be collected real-time as missile maintenance status changes. 

6. Inquiries must be answered with up to the minute information. 

7. The system must interface all users of the information with the 
suppliers of data. 

8. Missile quality assurance and data quality assurance must be linked. 

9. The system must be fail soft. 

10. No special skills or extensive schooling should be required to run the 
system. 

11. User programming should be optional. 

In addition, the MMIS should incorporate a Data Base Management System 
(DBMS) and a Decision Support System (DSS). These systems would prevent data 
redundancy and support semi-structured decision making. 



F. MMIS DISTRIBUTED NETWORK 

The MMIS should be configured as a distributed processing system, composed 
of a host computer servicing a number of satellite computers. Each satellite 
would be able to transmit and receive data from the host computer, and update 
host data files on a selected basis. The satellites would also be capable of 
independent data processing and should be able to communicate with the other 
computers in the network. The host computer would maintain all present mis- 
sile configurations, integrated maintenance histories, present maintenance 
status summaries, and pipeline location. 



G. DEVELOPMENT OF A MISSILE TRAVELER 

A missile traveler system should be developed. The traveler system recom- 
mended in the report follows the missile through the pipeline and integrates 
data collection, quality assurance, and maintenance status functions. The 
traveler would significantly reduce the paperwork requirements currently 
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imposed on maintenance personnel by eliminating missile log books, config- 
uration summary forms, maintenance action forms, and maintenance check lists. 
Integration of the traveler package with quality assurance functions should 
also increase data accuracy. 

H. PERFORMANCE STANDARDS 

Performance standards should be incorporated in the MMIS processing soft- 
ware to allow automated management by exception. There is a need to quickly 
identify maintenance problems such as abnormal reject rates of assets, delayed 
processing times, excessive buildup of non-RFI inventories, and excessive 
logistics downtime. NAVAIRSYSCOM (AIR-420) developed a number of performance 
standards covering many aspects of ALM maintenance processing. However, imple- 
mentation of these standards has been hindered by the inability to incorporate 
them in a viable MIS. 

I. AVAILABLE TECHNOLOGY 

The conceptual MMIS has no technical requirements which cannot easily be 
satisfied with existing technology. Therefore, selecting the appropriate 
technology becomes a trade off of existing technology options with their 
associated costs for optimization of the MMIS. The primary question will be 
between MMIS development and operation costs, and benefits to be achieved. 

The benefits should relate to asset readiness and the reduction of maintenance 
burden. 
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J. MMIS OWNERSHIP 



NAVAIRSYSCOM (AIR-420) must maintain ownership and control of the MMIS to 
ensure the success of the system. From a practical standpoint, NAVAIRSYSCOM 
(AIR-420) cannot assume control of computer systems of other commands nor 
should it delegate the operation of its system to other commands. A field 
activity such as PACMISTESTCEN would be an excellent choice for the develop- 
ment of the MMIS since this activity is a primary user of ALM maintenance 
information. The MMIS should be developed and operated by the activity that 
it is primarily designed to support. In the author’s opinion, this is an 
activity delegated responsibility for ALM maintenance management: PACMIS- 

TESTCEN. Three critical benefits are obtained by giving MMIS to its primary 
user. First, this user will strive to ensure system success because of the 
rewards offered. Second, the user is in the best position to integrate infor 
mation system functions with management functions. Third, this user would be 
forced to accept ownership of the information and would thus eliminate contro 
versy as to what information is pertinent. 
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III. DETAILED BACKGROUND 



A. NAVY MAINTENANCE POLICY 

The Navy's current maintenance policies follow three ideas: the All-Up-Round 

(AUR) maintenance concept, tri- level maintenance, and achievement of the ARO. 

The AUR concept attempts to deliver a missile to an operational squadron in the 
simplest, most reliable manner possible. Using the AUR concept, operational 
Fleet squadrons perform only minor assembly before installing the missile on the 
launch platform. In turn, the AUR concept allows shore activities to validate 
the status and condition of the missile with a minimal expenditure of labor, 
time, and money. The maintenance pipeline splits ALM maintenance into three 
levels. The extent of maintenance needed determines the number of levels 
required to ultimately accomplish repair. 

The first level, Organizational Level Maintenance (OLM) , encompasses the 
maintenance performed by Fleet operational squadrons. O-level maintenance 
generally consists of missile receipt, inspection, aircraft preparation, loading 
and downloading, basic functional aircraft checks, and installation and removal 
of wings and fins. 

The second level, Intermediate Level Maintenance (ILM) , encompasses the 
maintenance performed by an Intermediate Maintenance Activity (IMA) : a Naval 

weapon station or MMF. The IMA supports the operational squadron by providing 
an AUR that is ready for launch except for the attachment of wings and fins. 

I- level maintenance personnel conduct AUR tests of the assembled missile and 
replace defective missile sections. Missile sections requiring maintenance 
beyond I -level capability are sent to the Depot level maintenance. In addition, 
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the I-level unpacks and inspects AURs and sections, and repacks them when 
testing and cleaning have been completed. 

Depot Level Maintenance is conducted at activities called Designated 
Overhaul Points (DOP) . At this level, individual parts and subassemblies are 
replaced in sections that failed I-level tests and inspections. In addition, 
special maintenance actions, such as the regraining of rocket motors, are per- 
formed at the DOP. Completing the maintenance cycle, the DOP provides the 
weapon station with repaired sections which are ready for assembly into an AUR. 

Every year the CNO establishes the ARO, which serves as the goal to be 
achieved and maintained by the entire maintenance community. Asset Readiness 
(AR) is a fluctuating figure which specifies NAVAIRSYSCOM (AIR-420) performance 
of given missile inventory. It is expressed as the ratio between serviceable 
missile assets and the total numnber of assets in this inventory. Thus, the 
less time a missile spends in the maintenance pipeline, the higher the asset 
readiness figure. 

The central point in the pipeline is the weapon station. Here, new mis- 
sile sections from manufacturers are inspected and assembled into AURs. Fleet 
return AURs are also received for periodic tests and/or maintenance. After 
assembly and testing, or testing and maintenance, the AURs are packaged in 
containers for shipment. 

AURs are provided to the carriers from weapon stations 1 RFI stocks. The 
missiles are generally loaded on board a service force ship and transported to 
the aircraft carrier where they are transferred by vertical replenishment and 
stored in magazines in their AUR containers. During a deployment, the carrier 
unpacks only enough missiles for self-defense, usually about twenty percent of 
the on board air-to-air missiles. Carrier deployments are approximately one year. 
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While returning to home port at the end of the deployment, the carrier will 
undergo a Missile Pre-sentencing Inspection (MPI), known as Missile Sentencing 
Inspections (MSIs) prior to 1979, which evaluates the serviceability of all 
missiles on the carrier, thus reducing processing at the weapon station. Dur- 
ing the MPI, missiles are segregated according to another concept that is vital 
not only to the maintenance pipeline, but also to the MDCS itself. The concept 
of Serviceable-In-Service-Tirae (SIST) indicates the maximum period of time a 
deep stowed missile may remain in storage before it must be returned to a wea- 
pon station for periodic test. As will be discussed later, the concept of SIST 
significantly changed the Navy’s maintenance policy. 

Using SIST and the corresponding Maintenance Due Date (MDD) , personnel 
conducting the MPI segregate serviceable missiles from the unserviceable. 

Those which were captive carried, have an expired MDD, or insufficient SIST 
remaining for another deployment are pre-sentenced to be returned for weapon 
station testing. Deep-stowed missiles which have sufficient SIST remaining 
for the next carrier deployment are crossdecked to another carrier. Hence, 
the MPI screens the serviceable missiles for Fleet retention rather than 
returning the carrier’s entire inventory to the weapon station. 

Those missiles which require processing are then moved to the IMA where 
they are tested as AURs . If they pass, they are returned to RFI storage. If 
they fail, the section causing the failure is isolated and replaced. The 
defective section is then shipped to the depot for overhaul. 

At the depot the section is repaired and shipped back to the weapon sta- 
tion for assembly into another AUR or as a replacement spare. The time that 
missiles and missile sections are in the repair pipeline is determined by the 
efficiency of the maintenance system since individual test and repair actions 
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are accomplished in a matter of hours. The number of weapons in the pipeline 
at any one time depends on the number of missiles which are sentenced as 
unserviceable and the elapsed time required to return them to RFI condition. 

B. NAWMP DEFINITIONS 

In the early 1980s, NAVAIRSYSCOM (AIR-420) developed the Naval Airborne 
Weapons Maintenance Program (NAWMP), which serves to fully document mainte- 
nance policy for ALMs under the cognizance of AIR-420. This report examines 
the structure of AIR-420 f s management system, the Integrated Logistics Support 
System (ILSS), but concentrates on one ILSS element, the Management Information 
System (MIS) and its subordinating components. Definitions of the ILSS, MIS, 
and subsidiary subsystems have been extracted from the NAWMP in an effort to 
compare the way these systems were designed to operate and their actual 
operation today. 

The ILSS [Ref. 2] was instituted in the early 1970s as a means of decentra- 
lizing AIR-420 f s logistics functions. The ILSS is comprised of five systems, 
the primary system being the MIS. As defined in the NAWMP, "The MIS provides 
a capability for data gathering, analysis, display and reporting which is used 
by management personnel in the decision making process” [Ref. 3]. The system 
consists of five components which together are supported to provide an auto- 
mated maintenance monitoring capability. The first, the Problem Reporting and 
Briefing System (PRABS) is a "semi-automated management information, quick- 
reaction reporting system which provides procedures for collecting and 
reporting significant active problems and proposed solutions" [Ref. 4]. 

The Airborne Weapons Corrective Action Program (AWCAP) system is owned and 
operated by the Pacific Missile Test Center (PACMISTESTCEN) . It is used to 
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accumulate and track maintenance deficiencies of all air-launched missile 
systems and selected airborne ordnance/ammunition commodities. Problems are 
reported through Quality Deficiency Reports (QDRs), Engineering Investigation 
Requests (EIRs), and Safety Reports submitted by Fleet and shore based mainte- 
nance activities. The AWCAP report summarizes all active problems and reflects 
the progress of the investigation, including any corrective actions taken. 

The third MIS component is the Maintenance Data Collection System (MDCS), 
the primary maintenance data system for air-launched missiles. According to 
the ILSS, this system "providefs] a single source of maintenance data to remote 
and local data users, ,f and also f, collect[s] and store[s] as much detailed main- 
tenance data as can be reasonably obtained, while adhering to a simple, easy 
to understand data collection procedure 11 [Ref. 5]. As the Central Data 
Collection Agency (CDCA) , FLTAC designed and distributes forms for recording 
and transmittal of specific information regarding each reportable action. In 
accordance with the basic precept of MDCS, data is hand written on the form. 

As defined in the NAWMP, the last two segments of the MIS are two on-line 
data distribution systems presently operational at FLTAC. The Performance 
Monitoring System (PMS) has been designated as the "primary mode for presenting 
and distributing logistic management information" [Ref. 6]. The PMS maintains 
on-line displays available for logistics management users possessing remote 
terminal access. Through remote terminals, users can request summarized PMS 
data displays, including Mean Downtime, Part Replacement Rates, and ALM 
processing rates. 

The second information distribution system, the Information Consolidation 
Service (ICS), has been established as a method of "deriving selected infor- 
mation by the user... from data stored in the Integrated Data Base" [Ref. 7]. 
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ICS integrates the files of maintenance data with related reference files of 
supply oriented data. ICS outputs include summary reports and displays 
reflecting maintenance trends, reject rates, and average maintenance time. 

Although the definitions and procedures of the MIS have been clearly 
outlined in the NAWMP, the system is inoperable for reasons that will be 
discussed in the next section of this report. The current Management 
Information System is not answering the needs of the Navy f s maintenance 
community. The time has come to begin a change. 
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IV. HISTORICAL REVIEW OF MDCS 



A. MAINTENANCE DATA COLLECTION SYSTEM 

The MDCS component of the MIS was designed and is operated by FLTAC, for- 
merly the Fleet Missile System Analysis and Evaluation Group (FMSAEG) . Its 
development stems from the late 1960s as a response to OPNAVINST 4790., which 
called for an effective Maintenance and Material Management (3M) Program for 
air-launched missiles and targets. Although the NAWMP states that MDCS was 
developed as part of the ILSS, design concepts for MDCS predate the ILSS by an 
undefined period of time. Revision 2 of the ILSS Program Master Plan states 
that at the beginning of the program MDCS was "fully defined” and design 
(development) would begin immediately. At that time, the NAVAIRSYSCOM (AIR-420) 
organization was known as NAVAIRSYSCOM (AIR-4104). AIR-4104 began developing 

the ILSS in 1972 as a means of defining and systematizing ALM maintenance 
management functions. The ILSS program was instituted to decentralize and 
delegate authority of NAVAIRSYSCOM functions to cognizant field activities. 
Although in its infancy, MDCS was one of these existing functions. 

B. MDCS CAPABILITIES 

MDCS had originally been conceived as an entity in itself. At the time, 
however, little attention was given to the possibility of interaction between 
the various data systems of the MIS. Primary emphasis was placed on data 
collection, while data processing and information output were secondary 
considerations. Nevertheless, it was the ILSS which later defined MDCS as 
p rt of the NAVAIRSYSCOM (AIR-4104) MIS. As will be discussed later, little 



28 



effort was expended in restructuring MDCS itself. It was simply inserted as a 
component for the newly developed MIS. The additional requirements for inter- 
facing data processing and information output components were imposed on the 
two new elements, PMS and ICS. This decision lies at the very heart of the 
controversies concerning the validity and utility of MDCS: does MDCS fulfill 

its design function? 

The answer to this question is a hesitant yes, although with great diffi- 
culty and much uncertainty. PMS and ICS are acknowledged failures, and without 
any data processing or information output capability, MDCS cannot stand alone. 
Further, without these functions, the merit of the data within MDCS, and there- 
fore the merit of MDCS itself cannot be rationally evaluated. MDCS is an 
antiquated system in dire need of revision. Its current lack of credibility 
and the significant level of user bias favors the development of a new system 
rather than extensive revision of the existing system. The technology avail- 
able also makes it desirable to redefine the MDCS*s function so that it becomes 
an interactive element of a future MIS network vice a data collection system. 

C . MDCS DOCUMENTATION 

Program documentation from the early period of MDCS development is scarce. 
However, interviews with individuals involved with ALM maintenance at the time 
indicate that a systems approach was taken in an effort to collect all perti- 
nent data. MDCS was subdivided into three parallel subsystems to mirror the 
maintenance pipeline. 

1 . Shore Activity MDCS 

The first and most important of the three subsystems was Shore 
Activity Maintenance Data Collection. The Shore Activity MDCS was designed to 
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collect data concerning maintenance actions on air-launched missiles at the 
weapon stations and MMFs (the current MMF is located at Naval Air Station Cubi 
Point) . 

2 . Fleet Maintenance MDCS 

The second level, Fleet Maintenance Data Collection, was designed to 
collect maintenance, quality surveillance, and logistic-oriented data on 
air-launched missiles in the custody of the operational Fleet, including Naval 
and Marine Corps air stations. 

3. Depot MDCS 

The third level, Depot Maintenance Data Collection, was designed to 
collect overhaul and repair data for all air-launched missile guidance and 
control sections being maintained at various NARFs and contractors. FLTAC 
achieved varying levels of success in the development and implementation of 
the three subsystems. Primary emphasis was placed, and the greatest amount of 
success was achieved, with the Shore MDCS subsystem. General references to 
MDCS are primarily directed at the Shore based MDCS subsystem. 

D. MDCS DATA 

In the early 1970s, FLTAC began surveying individuals involved with ALM 
maintenance to identify applicable data elements to be included in MDCS. A 
major mistake in the development of the system was made at this time. After 
interviewing maintenance managers and engineers, a great deal of "pertinent" 
data elements were compiled. However, very little consideration was given to 
the actual utility of each of these data elements, or how the elements could 
be combined to produce meaningful reports. In addition to the interviews, 
OPNAVINST 4790. strongly influenced the definition of data elements. For 
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instance, the instruction required that each individual missile program be 
idenified, along with a capability to interface with other missile related 
data programs. Routine and corrective maintenance had to recorded, in 
addition to referencing technical directives, and the establishment of 
logistic audit procedures. 

These surveys resulted in two essentially standardized computer record 
formats. This first record format characterized maintenance actions, such as 
inspection, test, repair, and assembly of missiles and sections. The second 
record format characterized the configuration of built-up missiles. This 
included the part numbers of major components and service life information. 
Figure 1 lists data elements for the PHOENIX maintenance action record format. 
As can be seen, this record was long and complex. The PHOENIX maintenance 
action record contained 46 possible elements or fields with a maximum of 720 
characters. The size and complexity of the record led to some of the problems 
encountered with MDCS. First, the record placed excessive demands upon the 
individuals who were supposed to record the data. Maintenance personnel con- 
sidered missile maintenance to be their primary function and felt that data 
entry was an imposition. Second, some of the elements within the record could 
not be easily obtained on the weapon station floor. For example, the third 
data element called for the National Item Identification Number (NUN), and 
would be skipped if it was not directly accessible to processing personnel. 
Elements such as the NUN were probably meant to be completed at later stages 
in the data collection process. At any rate, the practice resulted in the 
generation of records with many missing elements. 

A second problem involved with the MDCS records was that their size made 
physical inspection and comprehension difficult. Neither CRT displays nor 
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printers could provide the data in a single line format, making it very diffi- 
cult to interpret. To compound the problem, software from the UNIVAC computer 
was used to compress the data. FLTAC programmers employed the symbol (@) as a 
means of condensing the record. For example, if the first two data elements 
in a record were the serial number and Naval Ammunition Logistics Code (NALC) , 
and the third data element, the NUN, was unknown, the record would look like 
this: @20125@PA55@<a. 

From the standpoint of data storage, this process had significant merit 
since these records could now be allocated a fraction of the space that they 
normally required. However, without some form of intermediary processing, the 
records became unintelligible. With 46 data elements, particular blocks of 
data were scattered at varying locations within the record. If ten consecutive 
data elements were skipped, for whatever reason, eleven consecutive symbols 
would be printed, making the actual data, what little there was, very difficult 
to read. This practice of data compression and the limited distribution of 
record format led to the development of an elite corps of FLTAC analysts who 
could translate the data. In effect, the data was scrambled and without rela- 
tively large machines and proper coding, it could not be deciphered. 

E. MDCS DATA COLLECTION 

Data collection for the MDCS subsystems was accomplished through multi- 
copy forms. Figures 2 and 3 are facsimiles of the forms used for SPARROW 
maintenance actions and configuration summaries for shore activities. It was 
originally intended that personnel directly involved with missile maintenance, 
afloat and ashore, fill out the forms, although this idea was quickly compro- 
mised. Carrier magazines were overcrowded and working conditions were poor. 
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Ordnancemen recorded the minimum essential data in pocket notebooks to be 
transcribed later to the MDCS forms by yeomen in Airborne Ordnance Control 
offices for eventual delivery to FLTAC. Naval weapon stations had developed 
their own paperwork (at first in the form of local worksheets and later as 
checklists adapted from particular maintenance manuals) to monitor their 
internal maintenance processing. Thus, the weapon stations considered MDCS 
paperwork as not only an imposition, but also needless. In addition, a sub- 
stantial portion of the data on the forms was codified in order to standardize 
compression and facilitate data manipulation. Again, the codification was 
highly desirable, and to a certain extent necessary, but it produced an extrem- 
ely unfriendly system. Few individuals knew what Julian date it was or what 
the Julian date would be in nine months, which was a required reporting element 
in many cases. Due to the codification and the additional paperwork, the wea- 
pon stations developed strong biases against MDCS. 

As a result, the weapon stations began designating "specialists" to com- 
plete the MDCS forms. These individuals were sometimes stationed away from 
the processing floor and often lost some understanding of the actual mainte- 
nance being performed. Their job was simply to transcribe data from one form 
to another. But due to a certain apathy among processing personnel, inaccura- 
cies often occurred during the translation. 

As mentioned earlier, the basic MDCS data forms were in multicopy format 
using a carbon paper-like transfer process. Actually, the forms were impreg- 
nated with a transfer medium whose density was less than desirable since most 
copies were difficult to read. The configuration summary forms had one origi- 
nal, which was sent to FLTAC, and four copies. Of the copies: 
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1. One was included as documentation kept with the particular AUR or 
missile section; 

2. One was kept at the weapon station missile maintenance processing 
building for approximately 90 days; 

3. One was kept at the weapon station data processing offices for several 
years ; 

4. One was usually destroyed. 

The copies acted as a safety measure to insure that data was not lost. The 
use and distribution of the copies had significant impact on future utility of 
the ICS module of the NAVAIRSYSCOM MIS. When troubles developed in ICS, weapon 
station personnel, maintenance engineers, and maintenance managers turned direct- 
ly to these hard copy MDCS files for direct access to data. To this day, direct 
access to these hard copy files is one of the most valuable although unofficial 
sources of MDCS data. In a way, use of these files may have relieved some pres- 
sure on ICS since vital information was ultimately obtained and problems were 
solved. On the other hand, use of these files probably increased criticism of 
ICS, since users were quick to point out that the data was available but could 
not be accessed within FLTAC T s data banks. It soon became apparent that if 
you dug hard enough, you could find the data you needed; but more importantly, 
FLTAC did not have the data in the MDCS. 

F. DATA STANDARDIZATION 

Considerable effort was expended to standardize data between different 
commodities. Data formats were essentially cloned. Certain fields were 
redesignated and coded to match specific missile configurations, performance/ 
test attributes, and endemic missile problems. It is not clear how well these 
data collection formats mirrored the actual missile processing procedures at 
that time. It is evident, however, that maintenance processing changed over 
the years, and that the data collection forms were not effectively modified to 
reflect these changes. The layout of the forms suggests that major emphasis 
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was placed on the logic of their development. The forms are systematic and 
appear to be complete. Nevertheless, approval of the forms seems to have been 
based solely on their logical appearance and apparent completeness rather than 
rigorous user proof testing. While the logical steps of maintenance process- 
ing are apparent, there are no clear definitions of the actual maintenance 
procedures. For instance, processing personnel were told to fill out a form 
every time a missile was tested, although the actual meaning of the word 
"test" was not clearly defined. Later studies showed severe discrepancies 
between the data of the three weapon stations [Ref. 8]. Today, the antiquated 
format and the tendency not to fully complete records leads to significant 
losses of vital data. 

G. CHANGING MAINTENANCE POLICY 

It is appropriate at this point to digress and discuss missile maintenance 
in the early 1970s and its impact on the MDCS subsystems. One of the primary 
contentions of this report is that a basic system and the management informa- 
tion system designed for that system are intimately related. The management 
information system must mirror, summarize, and predict the outcome of the proc- 
esses inherent in the basic system. It follows that if the processes within a 
system change, its management information system should be modified accordingly. 

H. IMPROVED REARMING RATE PROGRAM (IRRP) 

One of the biggest changes in maintenance policy occurred in 1966 when CNO 
instituted the IRRP. Many features of this program impacted ALM maintenance. 

For the first time, missile inventories were stored as AURs . Except for 
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Missile On Aircraft Tests (MOAT), maintenance and testing of missiles in the 
Fleet was eliminated. In addition, missiles were tested as AURs at the weapon 
stations. The benefits of the IRRP were many, and their impact on ALM mainte- 
nance was significant, if delayed. The IRRP was prolonged since its essential 
features required major modification of aircraft carriers. IRRP capability 
was immediately incorporated in aircraft carriers built subsequent to 1966. 
Retrofit of existing carriers took much longer, the last being the USS INDEPEN* 
DENCE in 1981. The transition from section to AUR based maintenance was a 
gradual one, taking place throughout the 1970s, both in the Fleet and at the 
weapon stations. 

The first major impact of the IRRP was the virtual elimination of the 
majority of Fleet I-level maintenance. While it took some time to convert 
over to the AUR concept, it was obvious from the start of MDCS development 
that Fleet MDCS subsystem requirements had been minimized. If there was no 
ALM maintenance performed in the Fleet, then there was little requirement to 
have a system to collect data concerning that maintenance. While data forms 
and an instructional manual were developed for the Fleet MDCS, in reality it 
was never really implemented. Type Commands resisted implementation of Fleet 
MDCS even in those Fleet units which were still performing significant amounts 
of Fleet I-level maintenance. Although the Marines were purportedly testing 
all SPARROW assets in their possession at 90 day intervals, a survey of MDCS 
files for the years 1974 and 1975 identified only three appropriate records. 
MSIs aboard carriers for the period 1976 through 1980 continually revealed the 
absence of any MDCS documentation in the Fleet. 
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I. TEST PRIOR TO ISSUE (TPI) 

In the early 1970s, ALM maintenance was dominated by a scheduled mainte- 
nance requirement defined as TPI. The TPI requirement specified that weapon 
stations only issue RFI assets to the Fleet which had previously been tested 
within a specified period of time, usually 180 days. This requirement pre- 
vented the stockpile of RFI missiles and forced weapon station workloads into 
a cyclical pattern in order to meet specified carrier onload requirements. In 
effect, the TPI requirement prevented the centralization of ALM maintenance 
management. In addition, weapon stations were forced to work with stocks on 
hand (both RFI and non-RFI assets) to meet loadout requirements. Except for 
budgeting constraints, weapon stations operated in a more or less autonomous 
fashion. Neither NAVAIR nor its designated agents had a significant amount of 
control over the actual scheduling of ALM processing at the weapon stations. 
Under this mode of processing, weapon stations operated comfortably, although 
inefficiently, using their own internal files, information systems, and 
sometimes physical inventory of magazines. 

The requirements for Shore MDCS under the TPI mode of operation were really 
not very significant since it did not have any management information function 
at all. Weapon stations operated autonomously and had their own data files. 
Missile processing had become almost automatic: all missile sections were 

tested prior to issue. Consequently, the weapon stations had little need for 
any additional data except the explosive component service life information. 
Reporting of missile processing was accomplished via subsystems other than 
MDCS. Under the TPI mode of operation, Shore MDCS functions appeared to 
collect data which could used for specialized investigative analyses (e.g., 
how many missiles were currently configured with rocket motors that would 
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expire in the next year). There was some intent to use MDCS data to charac- 
terize maintenance pipeline processes, but this was more historical in nature 
(e.g., 26 percent of the guidance/control groups tested on DPM-7 test set 
serial number 10 failed during FY-76). 

J. MDCS DECENTRALIZATION 

At this point, the relationship between the NAVAIRSYSCOM (AIR-4104), now 
NAVAIRSYSCOM (AIR-420), ILSS and the underlying MIS with its MDCS component 
merits discussion. The ILSS is best described by Revision 2 of the Program 
Master Plan, which was first approved in December 1974. With ILSS, NAVAIR- 
SYSCOM (AIR-4104) attempted to define its functions so that they could be 
decentralized to field activities. The ILSS Program Master Plan takes a for- 
mal systems engineering approach in the definition and control of subsystems. 
The ILSS and its subsystems were given life cycles similar to hardware. A 
subsystem's life cycle phases were related within a Work Breakdown Structure 
(WBS) matrix. The phases within the ILSS life cycle were: 



1 . 


Research 


WBS 


1000 


2. 


Analysis and Integration 


WBS 


2000 


3. 


Design 


WBS 


3000 


4. 


Operation and Evaluation 


WBS 


4000 


5. 


Full Scale Implementation 


WBS 


5000 


6. 


Maintenance and Control 


WBS 


6000 



The revision stated that the first three phases (with certain exceptions) 
had been completed and that the "major tasks to be accomplished were in opera- 
tion and evaluation, full scale implementation and maintenance control" [Ref. 9]. 
Specifically, MDCS was one of the ongoing "reporting" systems which had success- 
fully completed development concurrently with the research phase of ILSS (1972). 
By 1974, the planning for the remaining phases of ILSS was extensive. The com- 
pletion of the test and evaluation phase (WBS 4000) required documentation 
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validation, specification validation, and performance and demonstration at both 
the system and subsystem levels, along with a final assessment. The WBS tended 
to imply that deficiencies uncovered during test and evaluation would be cor- 
rected prior to, or during the full scale implementation phase. NAVAIRSYSCOM 
(AIR-4104) selected four problems to demonstrate ILSS capability: 

1. NWS and NARF workload coordination; 

2. Inventory projection; 

3. Evaluation of changing maintenance concepts at NWS; 

4. Engineering Change Proposal (ECP) evaluation. 

These problems were to be demonstrated on the SHRIKE and SPARROW missile 
systems, and the BQM-34 target system. The preparation of the system level 
demonstration plans and procedures was to require completion of subsystem 
demonstrations and preparation of subsystem inputs to the system level demon- 
stration plans. WBS 4131 was supposed to demonstrate that "the MDCS is capable 
of providing the correct information from all maintenance levels" Ref. [10]. 
These words infer that it was known at the time that MDCS did not provide the 
correct information from all maintenance levels since Fleet and Depot MDCS 
were inoperative, but perhaps had the potential of providing such information. 

K. ALM AVAILABILITY PROGRAM 

The true state of MDCS at the end of 1974 cannot be determined. Tests and 
demonstrations of the system were apparently never run. The ILSS program 
appeared to be generating excessive expense and absorbing a considerable amount 
of top management effort during a period of congressional concern over defense 
spending. Moreover, the mandate to decentralize NAVAIRSYSCOM (AIR-4104) func- 
tions had by this time lost considerable impetus. In fact, during 1975 and 
1976, some functions which had been delegated to field activites were reab- 
sorbed. As a result, the ILSS tended to lose significance as NAVAIRSYSCOM 
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management turned its attention elsewhere. Some elements, particularly PMS 
and ICS design, were nevertheless pursued. However, the overall system 
demonstrations were not performed or thoroughly evaluated. Had they been 
performed, the need for MDCS reform and improvement would have been evident 
much sooner. 

At the direction of CNO, NAVAIRSYSCOM (AIR-4104) instituted the Increased 
ALM Availability and Reduced Maintenance Burden Program in July of 1976. This 
program took advantage of the potential offered by the IRRP to significantly 
change the maintenance process for ALM. The increased ALM availability pro- 
gram had many attributes worthy of discussion and resulted in significant 
improvements in missile availability and in a reduction of maintenance expense. 
The increased ALM availability program was to be implemented immediately by the 
PACMISTESTCEN . The maintenance status of a large portion of the inventory was 
to be changed based on existing data. The TPI requirement was changed to SIST 
requirement for the majority of the inventory. This change in scheduled main- 
tenance requirements led to the capability to stockpile RFI missiles, and 
ultimately to centralize and control the management of I-level maintenance. 
Increased emphasis was placed on monitoring the efficiency of the maintenance 
system in terms of AROs . Significant improvements in AROs were to be obtained 
largely through improved management techniques. In addition, scheduled main- 
tenance was to be minimized by increasing SIST to the extent justified by test 
data. This mandate presupposed a cause and effect relationship between mainte- 
nance and missile reliability, which ultimately placed demands on the type of 
data which was collected and analyzed. 

The increased ALM availability program was initiated in July 1976 and 
implemented within 90 days. Initial guidelines for changes in ALM maintenance 
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procedures were issued via message in July. The brevity of the message and 
the resistance of personnel at the weapon stations led to controversy during 
August. Visits were made to all three of the weapon stations in an attempt to 
resolve both real and imaginary problems brought about by the new initiatives. 

The first real challenge to the increased ALM availability program came 
with the offload of the USS RANGER on 28 August. Program directives had 
specified that during offload (implying on board the carrier) , ALM assets 
requiring weapon station maintenance were to be segregated from RFI missiles. 

The SISTs for the RFI missiles were to be extended and marked on the missile 
containers in terms of revised MDDs . The people who were implementing the 
program decided that it would be impractical to establish SISTs for RFI 
missiles on board the USS RANGER, largely because they did not have access to 
the required MDCS (configuration summary form service life) data from FLTAC . 
Therefore, the decision was made to return all of the USS RANGER assets to 
WPNSTA Concord for segregation. 

During a ten day period starting on 11 September, a large number of SPARROW 
and SIDEWINDER missiles (80 percent of the USS RANGER inventory) were turned 
around and sent to the USS CONSTELLATION without significant maintenance proc- 
essing. Accomplishing this turnaround required use of the main missile 
processing building at Concord. Missile containers had to be opened to get at 
the MDCS configuration summary forms which had been packed with the missiles. 

The USS RANGER turnaround was considered a tremendous success because it rapidly 
made a large number of assets available and saved the Navy an estimated quarter 
of a million dollars in processing costs. The USS RANGER turnaround also 
taught the personnel who participated in it a lesson. The turnaround could 
have been conducted on board the carrier had appropriate data been available. 



41 



The second offload to be sentenced was the USS KENNEDY in December 1976. 



Starting in October, PACMISTESTCEN personnel requested MDCS data for the USS 
KENNEDY offload from FLTAC . FLTAC did not respond with any data. Personnel 
from NWS Yorktown accomplished the turnaround on board the USS KENNEDY using 
data extracted from the weapon station files. The turnaround was also a 
success except for some SHRIKE and WALLEYE assets which were erroneously sen- 
tenced for weapon station processing because it was not realized that the 
service lives of some explosive components had been extended. The first USS 
KENNEDY turnaround proved that container markings were not an adequate basis 
for sentencing missiles. 

L. MSI PLANS 

Missile sentencing aboard carriers for the period 1976 through 1985 and 
the corresponding MSI plans are appropriate subjects for this discussion since 
they probably represent the most extensive and most prolonged examination of 
MDCS data in existence. In the spring of 1977, PACMISTESTCEN began formali- 
zation of MSI procedures with the publication of an instruction. The primary 
feature of this instruction was that an individual MSI plan would be generated 
for each carrier. These plans were necessary since the required data was not 
available and sentencing rules were too complex to allow simple missile 
sentencing in carrier magazines. In effect, the plans pre-sentenced carrier 
inventories based on maintenance data. On board inspectors were there to 
verify the condition of missiles and to tag containers. Exceptions were to be 
recorded in MSI plans. The following data was required for the preparation of 
MSI plans: 
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1. Carrier inventory and deep stowage status, which was obtained from the 
Conventional Ammunition Integrated Management System/Serial Lot Tracking 
System (CAIMS/SLIT) . 

2. Missile test dates and service life data, which was be obtained from the 
Shore MDCS subsystem. 

The MSI plans tracked inventories and predicted the results of carrier 
offloads from the time the missiles were onloaded until they were offloaded, 
usually a period of a year. The active MSI plans combine to represent a large 
percentage of the Fleet inventory at any given time. In time, MSI plans 
became an effective management information system, if not officially recog- 
nized as part of the NAVAIRSYSCOM (AIR-420) MIS. 

At first, MSI plans were generated by hand. In 1978, however, efforts 
were made toward their mechanization. Automation of the plans facilitated 
periodic update. During 1977, hand written lists of MDCS data required for 
MSI plans were submitted to FLTAC. Mixed results were obtained from these 
submittals. Sometimes there was no response; other times the data was too 
late to be useful. Most of the time the data appeared to contain too many 
errors to be of any value. In efforts to obtain a better response from FLTAC, 
PACMISTESTCEN adopted the practice of requesting data via message with infor- 
mation copies to NAVAIRSYSCOM. FLTAC interpreted these messages as an 
aggressive move and communications broke down for a while. A rapprochement 
was achieved in 1979, when for the first time, the two organizations began 
working together. A special file known as CROSSDECK was set up under the ICS 
subsystem, enabling PACMISTESTCEN to enter serial numbers of assets which 
required MSI data. FLTAC was able to transfer these lists, screen MDCS files, 
and input the required data into the appropriate ICS file for retransmission 
to PACMISTESTCEN. This ICS file worked fairly well and requests were 
generally completed within a week. 
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For the first time, relatively large amounts of Shore MDCS data were 
scrutinized continuously. At first the data appeared to be incredibly bad, 
especially for recently loaded assets. However, over a period of time it 
became apparent that at least the test dates and service life data were intact 
and reasonably accurate and complete. The major problem was that FLTAC 
required an incredibly long time to get the data loaded into the UNIVAC 
computer . 

This long delay was nominally six months, but varied significantly. Even 
with the improved turnaround of the ICS CROSSDECK file, which had direct 
access to the primary MDCS files, the user was deprived of the last six months 
of weapon station data. Rather than admit that their collection system was 
inadequate and slow, FLTAC had been feeding PACMISTESTCEN obsolete data from 
previous maintenance cycles of the assets. The use of obsolete data was not 
limited to MSI plans, and probably occurred with most requests for MDCS data. 
The only accurate data obtained during this period was for those maintenance 
problems (requests for data) which viewed maintenance from a delayed histor- 
ical viewpoint. With the development of SIST, the improved ALM availability 
forced asset maintenance into a two to three year cycle. 

From a maintenance management point of view, the only important data was 
that which pertained to the current cycle since it reflected the maintenance 
status of the current inventory. The leisurely inclusion of data into Shore 
MDCS files dramatically compromised the picture that MDCS provided of this 
cycle. This slowness had a rippling effect. Not only were users deprived of 
six months of the most recent data, but they were instead fed the last six 
months of the previous cycle. The problem seems simple, but these effects 
were not obvious from isolated requests for data. Programs such as MSI 
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planning exposed the slowness of data input. MDCS data supplied for initial 
carrier onloads was incredibly bad. This data usually indicated that all 
assets loaded on the carrier, except those which were crossdecked, should be 
non-RFI. It was only as the carrier deployment progressed that MDCS data 
finally improved through monthly requests for data updates. By the time of 
asset offload, the data was fairly accurate. 

The delay of data input into Shore MDCS is probably the second most impor- 
tant failure of that subsystem during the last half of the 1970s and into the 
1980s. The slowness was important in its own right since it severely compro- 
mised the effectiveness of the subsystem. Of more significance, however, the 
delay was never officially acknowledged. The inability of management to recog- 
nize the problem probably contributed more toward MDCS subsystem damage than 
can be justified. FLTAC analysts were well aware of the extreme delay of data 
input to MDCS. FLTAC management tried to avoid the issue of the delay when 
possible, and defended themselves by stating that they had done their job by 
collecting the required data. If it was bad or erroneous, they blamed the 
weapon stations for not reporting the required data. If pressed, FLTAC manage- 
ment stonewalled and would admit to the two month delay between receipt of MDCS 
forms and the time data was entered into UNIVAC files. This generalization 
was consistently caveated with a further rationalization that data input had 
been currently curtailed due to the lack of funding. As such, data input 
became driven by FLTAC/NAVAIRSYSCOM (AIR-420) controversies over funding. The 
nominal two month delay in data input at FLTAC implied that the weapon stations 
were at fault in getting the data forms to FLTAC. Most users tended to reject 
this implication since they could obtain copies of the collection forms within 
a week of their generation at the weapon station. 
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As stated earlier, users of Shore MDCS data were slow to discover the 
extreme delay in loading the data into UNIVAC files and its impact on any 
resultant analysis. Isolated requests for data usually resulted in no data, 
or what appeared to be bad data. By the time the delay was discovered and its 
impact recognized at PACMISTESTCEN, efforts were well underway toward 
developing maintenance management subsystems which would project and predict 
maintenance pipeline processes years in advance. The development of SIST had 
given the weapon station the capability to stockpile missiles, and therefore 
the capability to schedule weapon station workloads. This, in turn, led to 
the capability to centralize maintenance management. On the other hand, CNO T s 
difficult AROs necessitated increased maintenance management to achieve the 
required objectives. The development of these maintenance management subsys- 
tems centers around another subsystem within the ILSS known as Workload 
Coordination (WLC) . WLC was defined as a subsystem of the ILSS Planning, 
Programming, and Budgeting System (PPBS), a distinct system from the 
NAVAIRSYSCOM (AIR-4104) MIS. 

M. MAINTENANCE MANAGEMENT 

The ILSS allowed NAVAIR to delegate the WLC subsystem function to 
PACMISTESTCEN in the fall of 1975. One of the primary functions of WLC is to 
generate a Workload Execution Plan (WEP) , which projects the ALM commodity 
workload requirements for I- and D-level maintenance at specific activities 
for the next five quarters. Originally, the WEP was generated by hand and 
required extensive liaison with Fleet and shore based activities to determine 
existing and anticipated Fleet loadout requirements and weapon station 
inventories. In 1975 and 1976, the WEP was marginally accurate in predicting 
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next quarter workloads, although projections for ensuing quarters were not 
given much credence. 

The improved ALM availability program placed significant pressure on 
increasing the accuracy of WEP projections. Initially, however, the initi- 
atives of the program, particularly the automatic SIST extension and on-site 
inventory of unserviceable assets at weapon stations, made the WEP projections 
highly inaccurate. The competition between the WEP and the improved ALM 
availability program created animosities within particular factions at PAC- 
MISTESTCEN for control of the maintenance management of ALMs . By the spring 
1977, personnel involved with MSI plans realized that the plans could be com- 
bined to form a more effective basis for WEP projections. At the time, WEP 
projections treated all offloaded assets as non-RFI while MSI projections 
separated assets as both non-RFI and RFI . Some of the RFI assets would be 
crossdecked and not returned to weapon station inventories. 

To some extent, the hostilities mentioned above prevented integration of 
MSI and WEP efforts at PACMISTESTCEN . The major factor preventing integration 
was that both MSI plans and WEPs were generated by hand. The great amount of 
effort, detail, and need for constant revision made the integration unfeasible 
at that time. Nevertheless, a major breakthrough occurred in February 1978 
when the Ships Parts Control Center (SPCC) agreed to start sending PACMISTEST- 
CEN monthly tapes of CAIMS/SLIT. With these tapes, PACMISTESTCEN began to 
quietly automate MSI plans. One of the things these tapes revealed was that 
missile status at the time of carrier onload and current MDDs were more 
accurately depicted in SLIT than in equivalent MDCS data. To increase the 
accuracy of the MSI plans, PACMISTESTCEN tended to ignore FLTAC MDCS input for 
the early stages of deployment and used slightly different SLIT data instead. 
To defend their position, PACMISTESTCEN argued that MDCS data was incorrect. 
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In February 1978, SPCC also began shipping monthly CAIMS/SLIT tapes to 
FLTAC for some undetermined reason. This tape was converted into a UNIVAC 
file, supposedly so that FLTAC could verify MDDs listed in SLIT records. It 
is not known how much of the SLIT data FLTAC used. To conform to the CNO 
mandate not to maintain duplicate data bases, little effort has been expended 
toward integrating SLIT and MDCS data. The integration of this data is, of 
course, one of the fundamental prerequisites of a viable NAVAIRSYSCOM (AIR-420) 
MIS. 

By the fall of 1978, PACMISTESTCEN had completed automation of MSI plans. 
Their execution from that time foward became an increasingly routine matter. 
PACMISTESTCEN informally transferred control of MSI plans and they became a 
WLC function. With this transfer, MSI plans became the driver for the WEP. 

Once the MSI plans became a WLC function, there was no longer any objection to 
their use as a basis for the WEP. 

At the same time, AROs of several primary assets declined drastically. 
NAVAIRSYSCOM (AIR-420) started remedial action including revision or redefini- 
tion of the ILSS in the form of the NAWMP, purge of the CAIMS/SLIT data files, 
institution of more accurate data reporting by CONUS activities, and finally, 
increased emphasis on management of maintenance processing. As part of the 
latter effort, NAVAIRSYSCOM (AIR-420) issued tasking to FLTAC to develop an 
automated WEP. This assignment was an afront to PACMISTESTCEN management 
since the WEP was considered part of their WLC subsystem. PACMISTESTCEN 
quietly started automating the worksheets which comprise the WEP, one by one. 
Efforts at FLTAC to develop an automated WEP floundered during 1979, 1980, and 
1981. It appeared hat they did not properly understand the maintenance proc- 
esses underlying the WEP nor the data elements necessary to characterize those 
processes . 
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In reality, obtaining this understanding was a simple matter. The WEP 
worksheets were in fact road maps and plans on how to construct an automated 
WEP. FLTAC did not want to import PACMISTESTCEN technology, but preferred to 
develop a new system of their own. By attempting to develop a new system, 

FLTAC took a significant chance. The PACMISTESTCEN had carefully tailored 
their system to mirror existing ALM maintenance processes. To deviate from 
the WEP or its underlying processes was to deviate from reality and introduce 
error. One of FLTAC' s fundamental mistakes was to attempt to drive their 
automated WEP wherever possible with MDCS data. In this application, MDCS 
data was simply not pertinent; MDCS does not contain the data required to 
develop a viable WEP. In 1981, the FLTAC effort to develop an automated WEP 
was cancelled with little if anything accomplished. The W"EP had already been 
automated at PACMISTESTCEN. 

The futile attempt by FLTAC to develop an automated WEP pinpoints a third 
more fundamental and philosophical problem with MDCS: the system probably 

contains very little data which can effectively be used in a NAVAIRSYSCOM 
(AIR-420) management information system. Although MDCS files contain the 
elements described in its documentation pamphlets, they are now obsolete. 
Fifteen years have elapsed since MDCS was designed to reflect a maintenance 
system that was autonomous and inefficient by today ? s standards. That main- 
tenance system has not existed for ten years, yet there has been little 
fundamental change in MDCS. The concepts of decentralization and the separa- 
tion and specialization of data bases have severely handicapped MDCS. MDCS 
may indeed characterize maintenance actions carried on with significant detail, 
but it does not reflect the overall framework of the process. In terms of the 
original intent as described OPNAVINST 4790., MDCS must be considered a 
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significant failure. It has little 3M utility either in the management of 
material or the maintenance thereof. 

By current standards, the WEP cannot be called an effective management 
information system either. It is, in fact, an automated, periodic report with 
no mechanized interactive or distributive capability. However, the WEP is one 
of NAVAIRSYSCOM AIR-420 1 s most effective maintenance management tools. The 
success of the WEP can be traced to the fact that it indigenously mirrored 
processes which its users wished to control. Emphasis was placed on charac- 
terizing procedures, not data. Users were free to select data from available 
sources. If MDCS had contained the best data, it would have been selected. 

It turned out that the CAIMS/SLIT data was of greater utility. Today the WEP 
is a fundamental part of the NAVAIRSYSCOM (AIR-420) maintenance management 
function. Although the WEP could be improved with further modernization, it 
should be utilized as a cornerstone in the development of a new MMIS. 

One final aspect of the improved ALM availability of 1976 which bears on 
MDCS was the mandate to "extend SIST to the extent justified by data." This 
mandate assumed that there was a causal relationship between the time interval 
at which scheduled maintenance was performed and the amount of failures which 
could be expected in Fleet inventories. This idea has considerable merit 
although it was later shown that failure rates were, to a considerable extent, 
time independent. The importance of the mandate was that it called for a new 
type of analysis or utilization of data which the ALM maintenance community 
was ill prepared to perform. Neither the existing maintenance processes nor 
data systems had been designed to evaluate such problems. To perform these 
analyses it was necessary o characterize certain aspects of maintenance. 
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1 . 



Fleet Exposure of Assets 



This data might have been available had Fleet MDCS been operational. 
Instead, PACMISTESTCEN collected this data during execution of MSI plans. 

2 . Asset Failures During Processing 

This data was available in Shore MDCS via ICS after significant time 
delays. It was often more effective to obtain copies of MDCS processing forms 
directly from the weapon stations. 

3 . Part Failures During Depot Repair 

This data may have become available in depot MDCS. The extreme time 
delay between failures in the Fleet and the part repair at the depot precluded 
this step in analysis. 

4 . The Cause of Part Failures 

The ALM maintenance process does not contain any provision for true 
failure analysis. Weapon Quality Evaluation Centers (WQECs) are sometimes 
funded on a missile by missile basis to perform such analysis. The resultant 
data is usually not contained in any data base, except possibly, AWCAP. SIST 
extensions were finally accomplished for SPARROW and SIDEWINDER missiles in 
1981 based on completion of steps 1 and 2 in the process noted above. The 
ultimate causes of failures or the reasons for the time independent failures 
were never determined. 

N. DEPOT MDCS 

Previous discussions have centered primarily around Shore MDCS. It is 
appropriate to briefly document the history and status of the third subsystem, 
depot MDCS. The ILSS recognized the need for data subsystems for each of the 
three levels of maintenance and had initiated their development in 1972. The 
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second revision of the ILSS Program Master Plan, dated December 1974, also 
claimed that development of all three MDCS subsystems was complete and test 
and evaluation would soon be implemented. As stated earlier, however, this 
test and evaluation never took place. It was also apparent that the develop- 
ment of depot MDCS was behind its Shore MDCS counterpart to some extent. The 
depot MDCS documentation manual was being circulated in draft format while its 
shore counterpart had been approved. 

In 1975, depot level maintenance of ALMs consisted primarily of repair of 
SPARROW (AIM-7E) and SHRIKE (AGM-45) components at NARF Alameda and repair of 
SIDEWINDER (AIM-9G) components at NARF Norfolk. Planning was in progress for 
depot level repair of emerging missile systems at various prime contractor 
sites : 

1. STANDARD ARM (AGM-78A) operational (1969) - General Dynamics, Pomona. 

2. PHOENIX (AIM-54A) operational (1975) - Hughes Aircraft Company, Tucson. 

3. SPARROW (AIM-7F) operational (1976) - Raytheon Corporation, Lowell. 

4. HARPOON (AGM-84) operational (1977) - McDonnell Douglas, St. Louis. 

The first major problem with the depot MDCS was that its implementation was 
initially delayed and sporadic depending on the missile system in question. In 
1975, FLTAC leased Mohawk terminals and contracted operators to perform coding 
at NARF Norfolk. It is noteworthy that these terminals were to transmit data 
directly to the FLTAC UN I VAC . Data was collected on forms generated by NARF 
Norfolk, so they had some control over data elements and coding. From all 
reports, operations at NARF Norfolk were fairly successful. They were super- 
seded, however, by a decision in 1976 to curtail SIDEWINDER repair at Norfolk 
concurrent with the deployment of the AIM-9H. In contrast to Norfolk, NARF 
Alameda resisted attempts to implement MDCS at their site. Alameda had devel- 
oped its own internal reporting system and considered MDCS an unnecessary 



52 



imposition. NARF Alameda successfully delayed the battle, arguing that formats 
and coding were awkward and unusable. The relative autonomy of NARF Alameda 
prevented direct imposition of MDCS reporting. It is believed that NARF 
Alameda did not consistently begin reporting until 1979. 

Depot MDCS reporting for the other missile systems was even more sporadic. 
During the period of 1976 through 1978, emphasis was placed on controlling and 
centralizing management of I-level maintenance at weapon stations. Weapon 
stations were considered the vulnerable link and the area where the most 
improvement could be obtained in terms of the ARO. Accordingly, depot level 
maintenance and depot level reporting were given less emphasis. It was not 
until 1979 that individual studies of the AIM-54A and AIM-7F systems and 
generalized SIST modeling proved that the slow turnaround of assets at depots 
had significant impact on asset availability. 

NAVAIRSYSCOM (AIR-420) has less control over depot level repair performed 
by prime contractors than it does with the remaining portions of the ALM main- 
tenance system. In the first place, prime contractors are strongly motivated 
by NAVAIRSYSCOM (AIR-05) development and acquisition contracts. While prime 
contractors consider depot repair efforts to be lucrative and necessary, they 
are certainly secondary to the major acquisition contracts. In addition, depot 
level repair efforts are often tied to major support contracts of which NAVAIR- 
SYSCOM (AIR-420) does not have full control. Most prime contractors prefer to 
utilize their own data systems and tend to view MDCS reporting as an imposi- 
tion. Experience indicates that NAVAIRSYSCOM (AIR-420) has had difficulty in 
enforcing MDCS reporting requirements on prime contractors performing depot 
level maintenance. Records for the periods in which Hughes Aircraft Company 
performed AIM-54A maintenance are spotty in MDCS. McDonnell Douglas resisted 
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all attempts to include HARPOON depot level repair in MDCS until 1981, at 
which time they dumped four years of data on FLTAC. The result was a mass of 
unintelligible and unverifiable data which has never been sorted out. Appar- 
ently, SPARROW AIM-7F and STANDARD ARM AGM-78A data from Raytheon and General 
Dynamics have never been incorporated in depot MDCS. Although the utility of 
depot MDCS is an open question, the subsystem has never been fully implemented 
and does not contain the data that it was designed to collect. 

0. SOURCE DATA AUTOMATION 

The discussion now turns to the history of the Source Data Automation 
Network (SDAN) and its predecessor, the SPARROW Information Network (SIN). 

SDAN was a FLTAC effort to improve one of the major problems associated with 
Shore MDCS: the extreme delay in incorporating data in MDCS files. The 

failure of SDAN or at least the extreme delay (nine years) in making SDAN 
operational has in effect precipitated the current controversy over the 
utility of MDCS in NAVAIR ALM maintenance management functions. 

As early as 1975, individuals at the working level believed that MDCS had 
significant problems and were voicing their criticism. This was also the time 
when advances in Transistor-Transistor Logic (TTL) technology had led to the 
introduction of the relatively low cost of minicomputers. The minicomputer 
provided an alternative to centralized computer information systems. Distri- 
buted networks of small computers with interactive capability were now 
feasible . 

In the fall of 1976, a group of individuals from NAVAIR, PACMISTESTCEN, 
and FLTAC proposed that a new maintenance data system should be developed in 
conjunction with the scheduled introduction of the SPARROW AIM-7F into the 
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Fleet in the spring of 1977. The group was funded and had the support of the 
SPARROW Program Manager, Air (PMA) . Since the system was funded by the PMA, 
it was designed to support a single missile system--the SPARROW. As mentioned 
previously, the new maintenance data system was to be called the SIN. For its 
time, SIN included many innovative features, including: 

1. Reassessment of MDCS data elements to assure their utility in management 
and logistics functions. Unofficial estimates indicated that at least 
fifty percent of MDCS data elements could be eliminated with no 
significant loss of function. 

2. Absorption of vital data elements from other data systems such as SLIT. 

3. Redefinition of data elements to reflect maintenance processes. 

4. Development of a missile traveler based on punched card technology to 
simplify data collection processes. 

5. Implementation of a distributed network of computers throughout the ALM 
maintenance community to speed data input to a central data agency; 
allow direct user access to central data agency files; allow development 
of user files and processing to specific site requirements. 

6. Allow interactive communication between all members of the network. 

In their zeal to obtain acceptance of their program, the advocates of SIN 
were quick to cite the inadequacies of MDCS. NAVAIRSYSCOM (AIR-4104) inter- 
preted these actions as a direct attack on its management policies, its data 
systems, and its supporters throughout the ALM community. NAVAIRSYSCOM 
(AIR-4104) did not like the attack initiated by the advocates of SIN, but there 
was a more fundamental problem. NAVAIRSYSCOM (AIR-4104) required a single data 
system controlled by its delegates to encompass all ALM assets. A proliferation 
of data systems acquired, and perhaps controlled by political advisaries such 
as the PMAs could not be tolerated. While SIN had significant technical merit, 
it had to be destroyed for political reasons. 

The major battle over SIN took place at FLTAC in the fall of 1977. The 
FLTAC advocates of SIN were judged to be insubordinate due to their continued 
support of the program and were transferred to positions having nothing to do 
with ALM maintenance. Simultaneously, NAVAIRSYSCOM (AIR-4104) supporters at 
FLTAC were given charge of an improved MDCS system which was to incorporate 
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many of the features of SIN. In the fall of 1978, FLTAC circulated a draft 
specification of the improved MDCS system to activities within the ALM mainte- 
nance community for review and comment. PACMISTESTCEN f s primary reservations 
at the time [Ref. 11] were: 

1. Review and modification of MDCS data elements had been eliminated; 

2. It was unclear that users would have direct access to central data files 

3. In particular, the equipment to be installed at PACMISTESTCEN appeared 
to have little or no data processing capability. 

In a strange turn of events, FLTAC requested that PACMISTESTCEN personnel 
assigned to NAVAIR-05 responsibility review the document. NAVAIRSYSCOM 
(AIR-04) representatives were not directly consulted. As a result, PACMIS- 
TESTCEN's concern was never directly conveyed to its NAVAIRSYSCOM (AIR-420) 
sponsor. On the other hand, the PACMISTESTCEN NAVAIR-05 representatives 
believed that their desires were being listened to. 

In 1979, FLTAC initiated prototype testing of a network by installing 
PRIME computers at Corona (a PRIME 750) and at the Fallbrook Annex (a PRIME 
450). Efforts were restricted to the transmittal of MDCS data of SPARROW 
missiles processed at Fallbrook to FLTAC Corona. This prototype testing 
encountered significant problems. Initially, there were problems in training 
personnel to operate the terminals. Secondary problems occurred with the 
definition of data elements and the reliability of validation routines and 
dictionaries. Hard copy forms remained as the the primary mode of MDCS data 
collection. 

In 1981 and 1982, FLTAC expanded the network by installing PRIME 450 
computers at WPNSTAs Concord and Yorktown. In addition, efforts were made to 
expand data collection to cover processing of SIDEWINDER and later, HARPOON 
missiles. The same problems which had occurred at Fallbrook also occurred at 
Concord and Yorktown. In addition, however, discrepancies started appearing 
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between data which had been obtained through processing the collection forms 
at FLTAC and that which had been transmitted via the PRIME network. Errors 
were not consistent since the validation procedures were not perfect. The 
increased amount of data flowing into FLTAC taxed the PRIME 750 storage capa- 
bility. Rather than having a stand alone capability, the PRIME 750 became the 
front end processor for the UNIVAC 1108. Differences in the PRIME and UNIVAC 
operations systems created problems with data processing software and data 
file structures. 

In 1982, FLTAC changed the name of the network from the Improved MDCS Sys- 
tem to SDAN and indicated that it was a component of MDCS primarily intended 
to eliminate the extensive time lag involved in processing input data. MDCS 
users, particularly at PACMISTESTCEN, felt they had been betrayed. Although 
FLTAC was finally admitting to one of the primary faults of MDCS, it was still 
not being eliminated. Due to the interface problems, data was only being trans- 
ferred from the PRIME to the UNIVAC in the form of batch processing at lengthy 
intervals of time. To users who interfaced with the UNIVAC data, input appear- 
ed as slow as ever. In addition, SDAN had become a data collection mechanism 
to a data system which no longer had any credibility. FLTAC had stripped all 
of the data reform and interactive capability from the network. 

In 1983, relationships between FLTAC and PACMISTESTCEN took an additional 
turn for the worse. When pressed about plans to expand the network, FLTAC 
representatives refused to admit that there had ever been plans to include 
PACMISTESTCEN in the network, and had no plans for installing a computer at 
PACMISTESTCEN in the future. PACMISTESTCEN was to be restricted from any 
direct access to data files and would be allowed only the preprocessed reports 
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from FLTAC. Such a situation was unacceptable to any individual at PACMISTEST- 
CEN who felt his function required access to maintenance data. 

According to the NAWMP, as of February 1985, I-level reporting of SPARROW, 
SIDEWINDER, and HARPOON maintenance is performed via SDAN, with plans for add- 
ing the remainder of the air-launched missiles and expanding the capability to 
include depot level reporting. The majority of MDCS reporting is still done 
using forms originated in 1975 (and subsequently revised). In the fall of 
1984, NAVAIRSYSCOM (AIR-420) requested evaluations of SDAN as a means of 
assessing of the viability of MDCS. In October 1984, NAVAIRSYSCOM (AIR-420) 
drastically curtailed funding for the operation of MDCS and has tasked both 
PACMISTESTCEN and FLTAC to initiate remedial actions toward development of a 
new or redesigned MDCS. 
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V. CONCEPTUAL MMIS CHARACTERISTICS 



This section presents material of a conceptual nature concerning the 
characteristics required for a new MMIS. The section is divided into two 
subsections. The first describes technology transfer principles which should 
be applied in the development of a new information system. These principles, 
although philosophical in nature, are considered more fundamental to the 
successful development of a new system than technical requirements. The 
second section lists conceptual technical requirements for the new system. 

A. TECHNOLOGY TRANSFER PRINCIPLES 

Technology transfer has emerged as a discipline to evaluate and improve 
the flow of information between a variety of entities, including individuals, 
organizations, systems, and perhaps machines. The application of this discip- 
line to information systems is especially appropriate since they are contructed, 
or require the integration, of all of the entities noted above. The flow of 
information is a critical factor not only in the information system itself, but 
in its conception, design, acquisition, evaluation, and operation. Although 
the principles of technology transfer may be considered philosophical in 
nature, they are perhaps more fundamental to the development of a new system 
than any of its physical or technical attributes. Failure to consider the 
principles of technology transfer could easily result in a disaster at some 
stage in the information system 1 s life cycle. 

Technology transfer is a topic directly related to the development of a 
new MIS. Most of us think of technology transfer as the flow of our newly 
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generated ideas, information, and methodologies to someone who can or will put 
them to use. bvic -sly, this is directly applicable to the MDCS, and therefore 
the MIS. Neither of these systems are functional due to the specific lack of 
information transfer. Based on this deficiency alone, the system should be 
foresaken. A closer look at the basic tenets of technology transfer provides 
some guidelines by which to design a new MIS. 

Within the air-launched missile logistics support system, there has been a 
‘ ^ndency to interpret informr on transfer as instructions, documentation, and 
structured repc 3 . The NA\v s an ex. ole. Technology insfer wever, 
occurs only when people work. Unless there is evidence of people T s ork output, 
there is no way to measure how much technology or information has transferred. 
While written reports and documentation are necessary, and in some cases vital 
to the success of new technology, they are certainly not the yardstick of tech- 
nology transfer. Most likely, management personnel accepted this interpretation 
because documenting and disseminating information were thought of as efficient 
procedures for transferring information. 

As developed by Professors J.W. Creighton and J.A. Jolly of the Naval 
Postgraduate School, technology transfer is defined as a "purposive, conscious 
effort to move technical devices, materials, methods, and/or information from 
the point of discovery or development to new users" [Ref. 12]. Thus, the 
result of technology transfer may be the user’s acceptance of a common prac- 
tice, or it may be a different application of a technique designed originally 
for another use. Two things must be apparent for transfer to take place. 

First, the user must have a clear knowledge of the practice or application 
required. Because communication or linkage between the user and the developer 
is not always close or effective, the urge is strong for the developer to do 
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what he/she wants rather than what the user requires. Since the MDCS was 
designed by FLTAC, many of its features do not serve its NAVAIRSYSCOM users. 

As with most innovations, the design of the system was an evolutionary proc- 
ess, including several system changes over a long period of time. For example, 
when a new missile entered the maintenance pipeline, the system was modified 
to incorporate its data. Soon, immense quantities of data were being col- 
lected but very little was being utilized. There was, and still is, very 
little control over the design of MDCS reporting elements. 

Secondly, the design of an innovation must demonstrate that the capability 
of the system actually offers substantial advantages to the business. Thus, 
simply disseminating information is not enough for technology transfer to take 
place; the information must offer rewards for its use. Information will only 
be sought to the extent that it is useful, and utilized to the extent that its 
value exceeds the cost of obtaining it. The manager values the information 
when it assists in decision making, otherwise the information has no value. 
Since there is a perpetual queue of information waiting to be assimilated 
outside of our minds, a transfer mechanism which recognizes the limitations 
and necessity of data dissemination must continually be defined. In other 
words, the source data for an innovation must fill the user's requirements in 
order for it to serve as information for a problem solution. 

In their studies of the technology transfer process, Creighton and Jolly 
developed what they call "The Linker Model," which identifies a list of neces- 
sary factors for the movement of technology or information from a source to a 
user. The linker is the individual or organization which links the source and 
user organizations; this is probably the most important factor in the transfer 
of technology. Linkers mediate between the user and developer organizations 
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and attempt to connect the user's requirements with the developer's output. 

The concept of the linker essentially enforces the idea that good communi- 
cations are highly important to successful technological innovation. 

The linker's importance cannot be overemphasized. The lack of a linker 
during the initial development phases of the MDCS has certainly contributed to 
the system's collapse. The various modules of the system, which were intended 
to reflect the maintenance pipeline, were all designed and supported by differ- 
ent units within FLTAC. These units were fairly autonomous in their operation, 
and consequently the modules evolved to the point where one could not communi- 
cate with the other. For example, if you wanted the complete maintenance 
history of a given missile, you would have to request data from each FLTAC 
unit. FLTAC would then trace back through the system to form an integrated 
missile history. This, of course, was time-consuming and expensive. 

Although the job of the linker is by no means an easy one, bypassing it is 
an assurance that the innovation will fail. By not employing a linker while 
developing MDCS, FLTAC generated a system to fit their needs and desires, 
rather than those of the maintenance managers who used the information. In 
developing a new MMIS and MIS, the system should be designed using the fol- 
lowing elements of the technology transfer linker model: 

1 . Selection Of Project 

This factor refers to the selection process of an innovation. In the 
case of MDCS, experience has shown that the basic reason for the user's inabil- 
ity to work with the data is because the selection process was done by others 
trying to perceive what the user needed rather than he wanted. In other words, 
the research for the project has come before the client's needs. In an optimal 
state, however, there should be a two way flow of in' rmation to both parties. 
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2 . 



Information Documentation 



This element defines the format, language, and complexity of an 
innovation ! s documentation. The format and language must be of a level where 
it is understandable by the user. One cannot utilize information that he 
cannot interpret. 

3 . Information Distribution 

Technology must flow from the source to the user in order to find 
application. The new MIS would depend on the number of entries and sophisti- 
cation of computer technology. The success of information distribution can be 
measured when people with problems can reach people with potential solutions. 
As noted previously, relations between NAVAIRSYSCOM user activities and FLTAC 
leave a lot to be desired. 

4 . Technical Credibility 

Credibility is an assessment of the information's reliability as 
perceived by the user. Since many users have trouble differentiating the 
source of information from the channel through which it flows, the user must 
carefully analyze the two elements before taking action. How the potential 
user perceives the information is crucial to the adoption or use of the 
technology. With MDCS , the data is viewed as faulty information owned by 
FLTAC rather than NAVAIRSYSCOM or weapon stations. 

5 . The Linker 

As noted earlier, the linker is the key factor in technology trans- 
fer. Linkers are not necessarily superior technical people, but are instead 
the sources of knowledge. 

6 . Formal Organization 

This element defines the formal organization of the information user, 
and his/her perception of his/her position within the organization . The 
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attitudes of these individuals often describe the overall character of the 
organization. However, the design of an organization should also be consid- 
ered when developing new innovations. For example, the Navy comprises a 
matrix of organizations, many of which need to be considered in order for 
technology to be adopted. 

7 . Individual Capacity 

Capacity refers a new user's potential to make use of new skills and 
information. This is an especially relevant factor when considering computer 
systems such as MDCS, which may or may not require the addition of new skills. 
When designing a new MMIS, a great deal of thought should be applied to whether 
or not weapon station technicians should input data. 

8 . Reward/Penalty 

The way in which a user observes the rewards (or lack of) affects con- 
siderably his/her own creativity and the adoption of new innovations. Extrin- 
sic rewards, such as good working conditions and a healthy salary, are obvious 
to most of the working community. Nevertheless, intrinsic rewards, such as 
intellectual stimulation and recognition among peers, are considerably more 
effective toward motivating people to be creative and efficient. For the MDCS 
user, one must question whether there is a reward in using the information. 

Is the user recognized for making decisions based on the information? 

9 . Willingness 

This element refers to the user's ability and/or desire to utilize 
the data or information. Successful adoption of an idea might take a long 
period of time from the instance when it was accepted intellectually. There 
are many reasons for the delay. Many people simply resist change and its 
rippling repercussions. With MDCS, the users' failure to use the data 
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immediately cancels any transfer of information. FLTAC ' s resistance to upgrade 
the system demonstrates their apparent laziness, but also proves the effects 
of financial change and organizational competency. Successful information 
transfer is contingent upon all of these elements. Forfeiting any one element 
detracts from the effectiveness of technology transfer. 

The MDCS should serve as the linking mechanism between the source of 
maintenance actions and the manager of the maintenance system. Rather than 
operating as a series of complex communication channels, the system should 
involve those performing maintenance with those managing maintenance. Linking 
the two sides is the vital element. When the user of an information system 
can be termed at the interface point between information output and need, the 
system is called a linker of source and user. 



B. TECHNICAL REQUIREMENTS AND SYSTEM OPERATION 

Although there are many conceptual models that can be developed for new 
MMIS, during this study the author developed a MMIS conceptual model which is 
presented in the following paragraphs. The MMIS should have the following 
technical requirements : 

1. The system must be controllable and auditable. 

2. The system must have integrity. 

3. The system should be economical to operate. 

4. The system must be user friendly. 

5. Data must be collected on-line as missile maintenance status changes. 

6. Inquiries must be answered with up to the minute information. 

7. The system must interface all information users with suppliers of data. 

8. Missile quality assurance and input data quality assurance must be linked. 

9. The system must be fail soft. 

10. Special skills or extensive schooling should not be required to run the 
system. 

11. User programming should be optional. 

The new MMIS would be a distributed system with a central data base con- 
taining a Data Base Management System (DBMS) and a Decision Support System 
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host computer data files. This process would create the initial file for that 
particular missile and would establish its present configuration and condition. 

2 . Comparison of Data Files 

Travel packages for missiles returned to weapon stations would be 
removed and compared with the data files from the host computer to insure data 
consistency. Any discrepancies would be cleared before maintenance actions 
are performed. 

3 . Verification of Data 

After determining that the travel package is correct, the missile 
would proceed through the maintenance process in accordance with the Indus- 
trial Processing Guide (IPG). The travel package would be updated by the 
missile maintenance personnel as maintenance actions are performed. At each 
quality assurance point, the quality assurance inspector verifies that the 
maintenance had been properly performed, verifies data entries, and updates 
host computer files. The host would be updated on a real-time basis. Each 
time data is entered, the host computer checks all data elements for validity, 
and records the quality assurance inspector f s identification for auditability. 
This process would assure correctness of data entered into the host computer. 

4 . Depot Rework Procedures 

When a missile section is sentenced for depot rework, the appropriate 
data form is removed from the travel package, updated, entered into the 
computer, and forwarded with the section to the depot where the same processes 
are performed by depot maintenance personnel. 

5 . Hard Copies of Maintenance Data 

If a travel package is lost, a new one can be generated by the host 
through inquiry made by the DPS. When travel packages are filled to the extent 
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that no more data can be recor r d, a new serialized package is generated by 
the DPS and the old travel package is forwarded for microfilming and archive 
storage. This process provides hard copy backup to the system. 

6 . Data Entry 

Data entry could either be by a centralized data terminal within the 
maintenance facility or by optical character reading devices at centralized 
locations within the maintenance facility. 

7 . Missile Deployment History 

A missile ! s deployment history would be contained on a form within 
the travel package. O-level maintenance personnel would complete the form 
during deployment, but the data would not be entered into the computer until 
the missile returned to the weapon station. MSI teams would insure that forms 
are filled out for the missiles utilized in Fleet deployments. 

Use of the travel package described above is merely an innovation on the 
missile logbook and the configuration summary forms that have been used for 
years. The new travel package system offers several advantages. The travel 
package would move with the missile. All the redundant data would be 
pre-printed. The maintenance personnel would only check off or add changes. 
The leave package broadens the scope of quality assurance to include data 
entry. Entry times and dates would be recorded by the computer during data 
entry. The travel package could be designed to follow the IPG and would be 
compared against its standards. There would be one set of forms, both for 
recording and accessing data by both Fleet and shore facilities. 

C. MMIS CONCEPTUAL ISSUES 

This concept contains a litany of issues that might suggest that the 
travel package and distributed system concepts are inadequate in meeting 
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requirements; that they are too complex, too difficult to manage, and too 
subject to risk and failure. On the contrary, the advantages outweigh the 
disadvantages. A distributed system is more robust. It would not be 
dependent on a single processor, a single manager, or organization. The 
system is more natural. Local functions are handled locally, rather than 
transferring great amounts of work to a central site with the consequent loss 
of local ownership and control. The distributed system links users of the 
information with the inputers of the data, provides for quality assurance of 
the data, hard copy backup, continually crosschecks new input with previous 
input, instantly updates maintenance actions and maintenance status, and 
allows for exception reporting to name a few advantages. The disadvantages 
include greater design sophistication and an unforgiving pressure on the local 
environment for reporting accuracy which could create problems in terms of 
project management. The distributed system will require higher levels of user 
skills and greater attention paid to planning for both data collection, form 
design, data input devices, DPS capability, the people involved, and their 
organization . 

D. STANDARDS OF PERFORMANCE 

Standards of performance enable management to control the production proc- 
ess. Distributed networks and travelers mirror the maintenance processes, and 
can play an important role in gathering and comparing actual performance data 
with established standards and reporting discrepancies for management by 
exception. As presently constituted, the MDCS does not have any programmed 
standards or mechanism to make performance comparisons except by manual means. 



69 



In recent years, NAVAIRSYSCOM (AIR-420) has developed standards for the pro- 
duction process. These industrial engineering studies, referred to earlier as 
IPGs, measure times required to perform the maintenance processes at the wea- 
pon stations. However, these standards are not programmed into the MDCS or 
its resultant information systems. Therefore, the managers must make their 
own decisions concerning what is or is not a maintenance problem. For example, 
none of the test equipment has established standards for nominal failure rates 
nor has there been any way of comparing maintenance actions or missile failure 
rates between different weapon stations. 

In 1981, PACMISTESTCEN commissioned a study to establish and analyze 
failure and rejection rates of SPARROW missiles as a function of testing on 
AN/DPM-21 test sets. The analysis contained 5811 individual SPARROW test 
records. These test records were extracted from MDCS files on magnetic tapes 
provided by FLTAC. With a sample of "his magnitude, the objects of the study 
should have been met and some nominal standards developed for the AN/DPM-21 
SPARROW missile rejection rates. However, due to MDCS data inconsistencies, 
missing data elements, erroneous source coding, bad operation codes, and non- 
standardized reporting practices, the study was not entirely successful in 
establishing failure rates of the different tests sets to determine if there 
was any kind of standardization. 

A critical factor in the maintenance process is Mean Logistics Downtime 
(MLDT) . This is the time the missile remains in the maintenance pipeline 
while waiting for a repair action to take place. MLDT seriously impacts asset 
readiness. At present, the only way MLDT can be determined is to manually 
track missiles through the maintenance process. 
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Figure 5 is an AUR/section flow diagram for the maintenance of an 
air-launched missile. The complexity of the network makes computerized 
standards extremely valuable in the management of the maintenance process. 
Use of the computer is the only feasible way of calculating and measuring 
performance of the maintenance system. Standards should be developed to 
measure and control the performance of the maintenance pipeline, and these 
standards should be programmed into any future MDCS. 
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VI. AVAILABLE TECHNOLOGY 



A revolution is underway. Most Americans are already well aware of the 
gee-whiz gadgetry that is emerging in rapidly accelerating bursts from the 
world f s high technology laboratories. But most of us perceive only dimly 
how pervasive and profound the changes of the next twenty years will be. We 
are at the dawn of the era of the smart machine, an “information age" that 
will change forever the way an entire nation works, plays, travels and even 
thinks. Just as the industrial revolution dramatically expanded the strength 
of man 1 s muscles and the reach of his hand, so the smart machine revolution 
will magnify the power of his brain. 



Newsweek , June 30, 1980 



A. EFFECTS OF TECHNOLOGY ON MANAGEMENT 

As the role of computers in organizations has matured, supporting the 
needs of the manager has become an increasingly important function. In cer- 
tain fields such as maintenance management, the requirements of the job demand 
the efficient use of the computer. But if information departments are to 
effectively fulfill the needs of the present day manager, they must develop 
systems which managers view as appropriate to their needs. Often it is pre- 
ferable to develop a new system rather than being constrained by obsolete 
technology and methodology in the modification of an existing system. 

Although the development of a new MMIS is a challenging assignment, it is 
a necessary move for NAVAIRSYSCOM users. Until recently, the main problem for 
organizations using computers was obtaining the adequate technology for the 
desired application. The current maintenance management community requires 
the generation and implementation of a new system which responds faster and is 
broader in scope than the current MDCS . Despite FLTAC ' s inefficiencies in 
controlling the data base and output devices, many managers still view the 
computer as essential to the organization. The technology to improve the 
system is available now. Developmental problems are strictly managerial. 
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Management of the system should become the responsibility of the user. 

For too long users have suffered from FLTAC 1 s ineptitude. As the designated 
CDCA, FLTAC has attempted to accumulate NAVAIRSYSCOM maintenance data, 
although in most cases it is in a form that is unidentifiable and therefore 
useless to its users. The problems with the current MDCS must be approached 
from two angles. First, FLTAC is governed by NAVSEASYSCOM, a competing Naval 
activity. While communication is never a simple process, dealing with an 
organization which follows its own set of rules can often times be chaotic. 

In this case, FLTAC is concerned only with the operation and maintenance of 
the system rather than the value the data represents to NAVAIRSYSCOM logistics 
managers and engineers. FLTAC 1 s basic premise seems to be, n It T s your data, 
we only collect and store it." 

In fact, this statement is true; the data belongs to NAVAIRSYSCOM and 
FLTAC 1 s job is to collect and store it. However, NAVAIR engineers and man- 
agers will not accept ownership of the data, nor will they attest to its 
credibility so long as FLTAC continues to run the show. This, of course, 
results in continuous inter-organizational conflicts, and more importantly, 
a total lack of control over NAVAIRSYSCOM 1 s information resources. 

The political ramifications of this problem have been lengthy and far- 
reaching. Over the past ten years, there has been an increasing effort to 
decentralize computer resources, including the differentiation of software 
from hardware, and the diffusion of technical expertise. Traditionally, the 
computer has been kept in a centralized, and often jealously guarded, organi- 
zational location. But with the advent of large-scale telecommunications 
networks, and mini- and microcomputers, the capabilities of the machine have 
been brought to the user. Although this progress will aid in the development 
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of alternative infc ..ation systems, it does not alleviate current relations 
with FLTAC, who have resisted the transfer of authority and information. 
Communications specialists tell us that when a competitive threat has grown 
great enough, there will be a resulting willingness to take the risks inherent 
in adopting a new technology. This is NAVAIRSYSCOM (AIR-420’s) current posi- 
tion. FLTAC has created boundaries which separate users from their own 
’’exclusive" data. And in so doing, they again point out that the dependence 
of others serves as the basis of power. 

B . COMPUTER DEVELOPMENTS 

As stated previously, computer technology is constantly changing. In the 
last several years, hardware advances have been incredibly rapid. There have 
also been similar though less publicized software improvements. Today, the 
generation of adequate software determines the speed and accuracy of computer 
based applications. As a result, computer software is an increasingly more 
important consideration than computer hardware. 

However, both are necessary considerations when developing any kind of com- 
puter system. Although the technologic advances in computer science have been 
almost immediate, this perpetual frenzy of innovation has left many computer 
buyers with obsolete systems. The PRIME 450 computers presently used at the 
weapon stations are examples. With an increasing number of effective computers 
on the market, the actual worth and utility of the PRIMEs is in question. In 
comparison to the computers of today, the PRIME is outdated. Today’s personal 
computers can probably fulfill the majority of user requirements, and some can 
even surpass the capability of the PRIME 450s. 
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With the abundance of items on today 1 s computer market, it is easy to buy 
a computer. How intelligently the computer is used ultimately depends on 
planning, which in turn depends on a clear knowledge of the business. In 
designing and buying a new system, it is also important to realize that the 
ubiquity of the computer demands the efficient reporting and storage of data. 
Many people no longer wish to see lengthy dissertations analyzing raw data. 
They'll analyze it themselves. The use of computers in our society is quickly 
reaching the point where to remain competitive, you must use a computer to aid 
not only in storing data but in making decisions. As a buyer of new computer 
hardware systems, NAVAIRSYSCOM (AIR-420) must also remain current with the 
computer industry in an effort to stay abreast of even further innovations. 

For example, at the present time, developmental efforts continue toward 
,r talking M to computers rather than typing the required information. There has 
been considerable achievement in this area and society cannot help but wonder 
when it will finally be consummated. 

The effects of this new technology and others like it on the maintenance 
community should be considered when purchasing a new system. Although the 
PRIME computers can still provide the information required, they are much 
slower to work with than a modern microcomputer. Advances in the design of 
microprocessors have led many users to expect data to be processed in real- 
time. 

C. SYSTEM ALTERNATIVES 

As an alternative to a real-time system, batch processing is also avail- 
able. However, n batching n information means that the user does not have 
access to the computer f s CPU. In batch mode systems, processing requirements 
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are collected at a central site, sorted, and processed as the computer has 
time. Batching obviously reduces the timeliness of reporting information, 
which in the case of MDCS, has been a determining factor in estimating the 
system 1 s worth. However, as opposed to on-line processing, batching is much 
more economical. In addition, it is an effective application when the delay 
caused by queuing data does not reduce the value of the information. On-line 
processing involves different degrees of processing speed. For example, a 
system may combine immediate on-line access for inquiries to the data base 
with batch mode operation for periodic update of records from a central 
collecting agency or remote site. Hybrid systems satisfy many requirements 
and are simpler and less expensive than real-time systems, which require the 
CPU to handle all inputs, outputs, and record updating immediately through 
on-line terminals. 

Timesharing is a term used in the computer industry to describe a proc- 
essing system with a number of independent, relatively low-speed, on-line 
terminals. Each workstation has direct access to the central processor. 
Multiprogramming allows the CPU to switch from one station to another, doing 
part of the job required by each. However, the speed of the machine allows 
the user at each terminal to feel as if he/she is the only one using the com- 
puter. The power of the CPU in comparison to the complexity of its tasking 
determines how close service approaches real-time. Many organizations are now 
using minicomputers in their timesharing system. This enables many different 
types of work to be accomplished at one time, including word processing, docu- 
ment filing, telecommunications, and various kinds of data processing. 

Organizations which require constant communication with other offices use 
computer networks known as distributed processing systems. When these dis- 
persed computers are connected by a communications network, the offices may 
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then transmit messages, processing tasks, and other informational data. The 
distributed processing network is actually an extension of timesharing, and 
enables its users to share some of the most significant software available 
today. This, of course, reduces the amount of idle CPU time, making the sys- 
tem more cost effective than a regular single user real-time system. With 
this increased availability of computer resources, many managers have easier 
access to the data and are therefore more readily prepared to make decisions 
for unusual problems. 

Unfortunately, the processing speed is often slower. Since the distri- 
buted system operates on the same essential premise as the timesharing system, 
the CPUs are constantly switching around to handle all tasks. As the number 
of users and associated complexity of processing requirements increases, the 
speed with which they are processed decreases. In addition, the costs of the 
distributed system may not always balance the quality of the computing service. 
One last potential disadvantage of the distributed system is its provision for 
protecting the confidentiality and integrity of user programs and data files. 
Although security programs are constantly improving the protective qualities 
of current systems, the methodology for cracking security systems is perhaps 
progressing at a faster rate. Of course, this does not mean that every 
type of distributed system is accessible to anyone. Once the decision is made 
to include classified data in the MMIS, security requirements significantly 
increase distributed system cost and complexity. It is believed that trade- 
offs will finally indicate that a hybrid system should be developed wherein 
nonclassif ied data will be distributed and handled on-line while classified 
data is processed batch mode off-line. 

As noted previously, one of the primary flaws of the MDCS data base is a 
lack of complete records. Data bases require that report elements be clearly 
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defined and consistently organized. In turn, this requirement demands that 
someone in the organization be given the authority to standardize or approve 
any necessary changes to the data elements. Control of the data leads to 
control of processing the software. With the advent of application software 
such as data base management, many users are now able to query the data base 
in a desired format without any particular knowledge of programming. 

As evidenced in the computer industry today, a user with a clear and well 
defined application to his problem can generally find a wide range of techni- 
cal building blocks. And although the jargon of the computer industry, 
"computerese, " may inhibit new users, there are many users with a clear sense 
of what computers do and how development projects must be managed. 
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VII. MANAGEMENT SYSTEMS APPROACH 



The systems approach to be employed for the development of the MMIS will 
consist of four phases: (1) the Study Phase, (2) the Design Phase, (3) the 

Development Phase, and (4) the Operational Phase. Each phase will be sub- 
jected to an iterative process of review and will result in a final output 
that can be used for determining the achievements gained by the activity. 

Figure 6 represents the life cycle of the system and products that will give 
utility for judging the results of each phase. The management approach will 
be results oriented. 

A. THE STUDY PHASE 

This phase is the initial effort to define the overall MMIS strategic plan 
and development of a systems performance specification. The effort will result 
in the assignment of a data base manager, establishment of a study team, and 
execution of a fact finding process. During this phase, the requirements for 
data and report formats will be identified and input/ output requirements will 
be established. The development of system flow charts and the selection of 
the most practical equipment (considering what is already available) will 
occur . 

The study phase will culminate in a System Performance Specification (SPS) , 
which describes the objectives of the system, identif icaton of the internal 
and external constraints (such as existing equipments that must be considered 
for use) and a feasibility study on the use of converting currently collected 
data into required reports. Another significant product of the study phase is 
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the MMIS Life Cycle Management (LCM) Plan. The plan will be a dynamic tool 
that will identify the manpower and resource requirements necessary to imple- 
ment and operate the MMIS throughout its life cycles. 

B. THE DESIGN PAHSE 

The SPS developed under the study phase establishes the basis for further 
effort in the design phase. The primary effort under the design phase is to 
evaluate performance requirements and perform trade-off studies with current 
computer technology. The efforts performed in the design phase will extend 
and expand the first and second tier systems defined in the study phase, and 
will consolidate hardware and software functions. A Design Specification will 
be prepared that delineates the system's architecture required to satisfy 
performance requirements and will include MMIS decisions as follows: 

1. Determination of manual and equipment functions/operations; 

2. Hardware and computer interface requirements; 

3. Type and functional programming requirements; 

4. Data base design; 

5. Storage media, processing requirements, and access requirements; 

6. System and programming test requirements; 

7. Identification of distributed processing requirements. 

The design phase will conclude based on approval of the Design 
Specification and acceptance of an updated/revised MMIS LCM Plan. 



C. THE DEVELOPMENT PHASE 

There are seven principle tasks to be performed during the development 
phase of the MMIS. They are: 

1. Internal/external computer programming (external is required in a 
distributive computer system); 

2. Preparation of implementation plans, technical manuals, and training 
devices ; 

3. Acquisition, installation, and debugging of new hardware (if required); 
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4. Preparation and verification testing of system/subsystem/component 
performance; 

5. Preparation of Systems Specification and "as built specification"; 

6. Establishment of hardware/software baselines and change control 
procedures ; 

7. User reviews, problem identification, and software debugging. 

The basis of all these tasks lies in the Design Specification prepared and 
approved from the preceding phase. To ensure acceptance of the MMIS during 
the operational phase, a primary requirement is to use a lot of grease with 
all the known users. This requirement is best accomplished through the itera- 
tive process of user reviews and proper indoctrination training. Resistance 
is usually less when users are made part of the development process. There 
are two major elements of the development phase. They are: 

1. Establishment of an operational system; 

2. Identification and control of the system through a System Specification 
and change control process. 

Successful completion of the first three phases brings to fruition an 
operational computer based MMIS. At the conclusion of this phase, the MMIS is 
placed into operation. 

D. THE OPERATIONAL PHASE 

The transition from the development phase into the operational phase is 
hard to distinguish. The training that is performed during the development 
phase overlaps into the operational phase and will continue on a periodic 
basis during the life cycle of the MMIS. Users will operate the system and 
acquire the necessary information to control the maintenance pipeline. As new 
systems emerge and data requirements change, it is important to implement a 
change system that can keep pace with the evolving requirements for new and 
better information . 
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Even though the system is operational, a continuous forum should meet on 
a periodic basis to discuss problems, propose changes, and monitor change 
efforts. On an annual basis, a team should be formed to perform an audit type 
inspection testing of system/subsystem/ component performance to give the new 
MMIS a checks and balance system to ensure its integrity. 

E. STRATEGIC PLANNING FOR THE IMPROVED MMIS 

The degree of success of an operational computer based management infor- 
mation system can be directly attributed to the strategic plan used throughout 
the system’s life cycle. The improved MMIS will require a comprehensive man- 
agement plan that will consider the management strategies to employ. The 
strategic plan will be addressed as an LCM Plan and will provide the practical 
framework for the controlled growth of the MMIS. 

The MMIS LCM Plan will be a dynamic tool that documents information system 
policy and information resource management. The plan will encompass the manage- 
ment structure and responsibilities, informational and equipment requirements, 
project activities, schedules and milestones, and cost controls. The dynamism 
of the plan will be represented by continual change that results from evolving 
innovations in technology as well as decisions associated with informational 
requirements. The plan will be an integral part of the MMIS and will give the 
foundation of total planning for effective, efficient, and affordable accom- 
plishment of mission information system needs during the system’s life cycle. 

F. STATEGIC PLANNING RESPONSIBILITIES 

The MMIS LCM Plan will be prepared by the lead activity responsible for Data 
Base Management (DBM). The NAVAIRSYSCOM should designate the PACMISTESTCEN as 
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the activity responsible for the MMIS DBM. The LCM Plan will be prepared and 
maintained current by the PACMISTESTCEN. 

The PACMISTESTCEN is responsible for establishing the management hierarchy 
for development of strategic plans and definition of data and informational 
requirements. The PACMISTESTCEN is in the best position to accomplish this job 
since their awareness of informational needs for accomplishing mission objec- 
tives at the strategic, tactical, and operational levels cannot be matched by 
any other organization. The strategic plans will be formulated from every 
perspective with sensitivity to all levels of informational requirements, 
emphasizing user selectivity and accessibility. 

G. MMIS DATA BASE MANAGER 

The PACMISTESTCEN will organize internally to build the MMIS strategic 
plan and initiate development efforts. A data base manager will be assigned 
who has the reputation and expertise to represent the PACMISTESTCEN within 
NAVAIRSYSCOM and other activities. The data base manager will be required to 
make significant contributions to strategic planning and system development 
efforts by being fully aware of three key elements: 

1. The composition of the maintenance pipeline currently consists of the 
informational requirements for effective monitoring and control. 

2. Knowledge of MMIS user informational/data requirements from field and 
command level prospectives ; 

3. The ability to effectively interface with activities /commands outside 
the NAVAIRSYSCOM to ensure proper integration of all necessary data into 
the MMIS. 

The data base manager will be required to make decisions relative to system 
formulation and informational requirements; to this avail, the PACMISTESTCEN 
designated data base manager will be a GM-14, temporarily staffed to the Wea- 
pons System Directorate for a period of one year during intensive initial 



83 



system development. Due to the relative significance of the initial develop- 
ment effort and the lack of any means of obtaining the necessary data to manage 
the maintenance pipeline, heavy emphasis will be placed on expediting system 
development that will necessitate the data base manager to be dedicated to 
MMIS development without collateral duties. 

The data base manager will be the focal point for strategic plan 
development. NAVAIRSYSCOM (AIR-420) will retain policy decisions and plan 
approval responsibilities. The data base manager will work closely with 
NAVAIRSYSCOM (AIR-420) in the preparation of the MMIS LCM Plan to ensure 
consistency with current and future NAVAIR policies and initiatives. 

H. MMIS STUDY TEAM 

The data base manager will draw together a study team that will be 
comprised of representatives from all future users of the MMIS, computer 
specialists tasked with equipment and programming responsibilities, and other 
significant contributes to the proper development and implementation of the 
MMIS. The study team will be the nucleus for defining system performance 
requirements and will be the main contributor of the MMIS LCM Plan. 

Meetings of the members of the study team will be held on a monthly basis 
to discuss user requirements, develop performance requirements, and to review 
action assignments. During the study and design phases, meetings may be called 
on a more frequent basis to allow for expediting system definition and develop- 
ment efforts. The data base manager and other study team members may elect to 
interview others to obtain information necessary to further understand poten- 
tial areas that might require data or information, or provide a source of 
input data. 
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I. MMIS INFORMATION AND EQUIPMENT REQUIREMENTS 

The reason for establishing the MMIS is to provide users with information 
and data in a form and frequency that will improve the maintenance management 
function. The identification and development of these requirements will be 
contained in the MMIS LCM Plan and will be done through a fact finding process 
that allows future users to convey their ideas and reporting requirements. 

The fact finding process will be accomplished by the data base manager and 
study team during the study phase. User data requirements will be documented 
in broad terms in the MMIS LCM Plan, with expanded requirements being identi- 
fied in the SPS. 

During the design phase, user data requirements will be measured against a 
number of system considerations and trade-offs. The feasibility of obtaining 
and producing the necessary information to satisfy user needs will be deter- 
mined. The MMIS LCM Plan will be updated/revised to reflect informational 
decisions made during this phase. 

J. PROJECT ACTIVITIES AND THE MMIS LCM PLAN 

The MMIS LCM Plan will have a comprehensive section on the who, what, when, 
and where of all project activities required during the initial phase of system 
development through implementation. The MMIS LCM Plan will be updated/revised 
as system requirements evolve into operational status. The plan will be dyna- 
mic, even in the operational phase, by delineating events that will be required 
throughout the system life cycle. Examples of activities that will be addressed 
are future system audits and performance appraisals, new development initiatives/ 
system changes, and establishment of technological advancements. The MMIS LCM 



85 



an will be maintained during the MMIS complete life cycle and will be used 
for guidance and providing information on planned project activities. 

K. MMIS SCHEDULES, MILESTONES, AND COST CONTROLS 

The initiation of a master plan for establishing schedules for tasks and 
milestones for events is necessary. This will be accomplished through the use 
of a management analysis and planning network known as Critical Path Method 
(CPM) networking, which is similar to the Program Evaluation Review Technique. 
CPM graphically displays task requirements and relationships, and forces man- 
agement to construct a network which will act as a master plan for accomplishing 
project activities. 

CPM will be employed to control the complex project events associated with 
the development of the MMIS. The CPM network insures total planning from pro- 
gram initiation to the operational phase. CPM will be used to identify 
schedules for task activities and will project MMIS program milestones. The 
CPM networking process will identify a critical path which will require manage- 
ment focus and continual attention. The CPM networking techniques will assist 
the DBM in controlling loss of time and project costs. 

Project costs will be results and output oriented. The MMIS LCM Plan will 
identify man-hour requirements and costs associated for completion of major 
milestones. A detailed cost analysis will be performed in conjunction with 
CPM network events and actual expenses will be assessed against program 
accomplishments. Cost projections will be refined as more definitive system 
requirements are developed. Cost considerations will receive the micromanage- 
ment attention to achieve program objectives within cost projections. 
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MAGNETIC TAPE RECORD DESCRIPTION 



CARD 


CHARACTER 

POSITION 


FIELD 

NAME 


LENGTH 


1 


1-20 


C.I.I.D. 


20 


1 


21-37 


C.I. SERIAL NO. 


17 


1 


38-43 


C.I. DATE 


6 


1 


44-47 


C.I. TIME 


4 


1 


48-52 


"SMDCS" or "FMDCS" 


5 


1 


53-56 


REPORTING ACTIVITY 


4 


1 


57-80 


ITEM/MK/MOD 


24 


2 


1-20 


ITEM PART NO. 


20 


2 


21-37 


ITEM SERIAL NO. 


17 


2 


38-80 


MATED ITEM SERIAL NO. 


43 


3 


1-24 


MATED ITEM SERIAL NO. 


24 


3 


25-30 


ACTION DATE 


6 


3 


31-34 


ACTION TIME 


4 


3 


35-36 


OPERATION CODE 


2 


3 


37-51 


TEST EQUIPMENT TEC, 
SERIAL NO. 


5 


3 


52-53 


ITEM SOURCES 


2 


3 


54-55 


MATED ITEM SOURCE 


2 


3 


56-57 


MATED ITEM SOURCE 


2 


3 


58-59 


MATED ITEM SOURCE 


2 


3 


60 


TEST/ INSPECTION RESULT 


1 


3 


61 


MATED SECTION RESULT 


1 


3 


62 


MATED SECTION RESULT 


1 


3 


63 


MATED SECTION RESULT 


1 


3 


64-66 


DISPOSITION CODE 


3 


3 


67 


CONDITION CODE 


1 


3 


68 


DEFECT CODE 


1 


3 


69-72 


NALC 


4 


3 


73-80 


FSCM 


8 


4 


1-4 


TEC 


4 


4 


5-13 


wuc 


9 


4 


14-30 


niin 


17 


4 


31-44 


LOT NO 


14 


4 


45-49 


MGFR . DATE 


5 


4 


50-54 


T1 


5 


4 


55-59 


T2 


5 


4 


60-80 


T3 


5 


5 


1-80 


FAILURE CODES 


80 


6 


1-80 


FAILURE CODES 


80 


7 


1-6 


DATE ASSIGNED 


6 


7 


7 


TRANSFERRED 


1 


7 


8-12 


TO /FROM ACTIVITY 


5 


7 


13-80 


JOB ORDER NO 


68 


8 


1-80 


REMARKS 


80 


9 


1-80 


REMARKS 


80 



Figure 1. PHOENIX Maintenance Record Format. 
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List SPARROW being disassembled on first line. Enter all removed sections on subsequent lines. 



SHORE activity maintenance OaTa COLLECTION - CT»PIGURaT>On SUiuAJIT 

SPaR« 0» (It (ALMS' 

MAVklA aYVO^S (Till i«t» 1-77) 


REPORT IYmROL tunii Am-S(7li 


MiMl»TM.«(i j 1 %T( 

£oo/ 73/8 


1 »«Mi*Cv»yt ai/N: 1 ft»t f. 4 f-o*. •*»>««• i Ul KMin . n**.? 

_ A"? j/+jo -oo- 520 - /23 / R~4oSQ-foH-5 ' pA70 


t w»iC/o«e coot 


I M( t iOm 

U/SD 73 18 Soo/ 


J 14 /MO4MI/M0O (Ml 4Ut« 

| 30SZOIO 


II U-* <**» »J 4* t 


it 

NOMENCLATURE mk-mOO^TYPE DRab-PaRT mO 


1 IJ 

1 SERIAL NUMBER 


u 

LOT number 


i >< 

FSCM/MFC 


1" LOAO I" 

CURE ''MFC en» DATE 

DATE 


TUIfT W(*fl GROUP 


f?4o58-bH£ 






i 


ESn 








1 




PLtO-T CONTROL GROUP 


Zio3 b«5 






! 




ESN 








i 




raRmE aO'E *E RO SE hEaO 3© O 


ZSI5 


7-5 






07-^4- 


EJn 












UEET> AHD a»hi(< OCviCC 3S O 


/ 2-7 


l 


r 


IZ-6T 


IZ-8 3 


E In 


[ 




1 






44 _ 4 00 

ELCCTROk-C Firing SWITCH 70 2— 


376 / 


B 1 


I’L *6 4- 


I/Z.-84- 


E IN 


! 1 

i 






rooster e .. re “ 38 ** ( 


— 


2- M 




c?3 2 . 


,<73 - 02 . 


ESn 1 






i 




f 


rocket no^or **38 “°° 4 - l3#4 -OOC9t>(o 


5KEI 


<73-6? 03-77 


ESN 


1 


i 


“265 ■“ o 1 ^-r-360?o V 


1454-8 


ot-85 


M4 adb 

TLh 






t 

ESn 






EPu -EuEL STtCA) " C/AJ K "°° 


VkZSlSio 


06-47 06-81 


•* mOL 

e>u n o#iTe»i 


80 




0 3-6? 0 3-85 


»t Uoff 

GPU 


8G 




o?-15 


' o?- ?5 


HPu-tf (GaS Tank) 




U K. 








L» «oo 

hPU-h (RURRER BLAOOEB- 


1 


u ^ K 






mPu-h (E KPLOSIVE aCTuaYOR' 


/-/4 


05- 6 3 1 05-81 


BIT ■ " " «or 

BATTER* (YE i 




J 




GAS OEnERaTOP (YE) 








ILECYROniC ACTIVATOR (YE) 




J 








craole/ container - 470 “°° O 




i 




j 




*P»\/ 34 . 


/ £A 






1 




*/r zw 9 7 1 


1 Ser 










" 












C/5 SCALS •* 


‘ 15/0 5 






| 

. -j 




| 


554-82- 




i 






11 ALTERATIONS technical DIRECTIVES 


■ aivERS 


A u/c-/ oV ! 


| 

1 T 


7 3/8 


7236 


S/S 7 90*90 


N. 41 4A/ 4CC 


a MI*fCT04 atAlial 


» taji» »•»« coot 1 r *».• coo* 


m corno coot 









Figure 3. SPARROW Configuration Summary Form. 
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DPS = distributed processing system 
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Figure 5. IPG AUR/Section Flow Diagram 
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Figure 6. Life Cycle of MMIS. 
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